classloader.loadclass() 或 class.forname() 找不到类时抛出 classnotfoundexception，主因是运行时 classpath 或模块路径缺失字节码、类加载器隔离/委托异常、模块未导出或未声明依赖。
ClassLoader.loadClass() 找不到类时抛出
这是最典型的触发场景：代码里显式调用 ClassLoader.loadClass() 或 Class.forName()，但 JVM 在 classpath（或模块路径）中查不到对应类的字节码文件。
常见错误现象：ClassNotFoundException: com.example.MyService，但你确认类名拼写没错、也写了 import —— 问题往往不在源码，而在运行时环境。
- 检查该类是否真的打包进 jar / war / class 目录：比如 Maven 项目没加
compile范围依赖，或依赖被<scope>provided</scope>排除了 -
Class.forName("com.example.MyService")默认使用当前线程上下文类加载器（TCCL），不是当前类的类加载器；如果在 Web 容器（如 Tomcat）里，TCCL 通常是 WebAppClassLoader，而你的类可能在 shared/lib 下，没被它委托加载 - Java 9+ 模块系统下，即使类在 classpath，若所在模块没
exports对应包，或调用方模块没requires，也会报这个错（严格来说是NoClassDefFoundError的前置条件，但表现相似）
反射调用 newInstance() 或 getMethod() 前未确保类已加载
很多人以为 Class.forName() 成功就万事大吉，其实后续反射操作仍可能触发二次加载 —— 尤其当目标类有静态初始化块，且依赖另一个尚未加载的类时。
使用场景：框架（如 Spring、MyBatis）解析配置中的全限定类名并实例化 Bean；自定义插件机制通过反射加载扩展类。
立即学习“Java免费学习笔记（深入）”；
- 不要只捕获
ClassNotFoundException，还要留意ExceptionInInitializerError，它常包裹一个底层的ClassNotFoundException - 避免在
static {}块里做动态类加载，否则首次访问该类就会失败，且无法重试 - 若必须延迟加载，用
Class.forName(name, false, loader)（第二个参数设为false）跳过初始化，等真正 newInstance 时再触发 —— 这样可以把错误时机延后到可控位置
Web 应用中 WEB-INF/lib 与容器 lib 冲突或隔离失效
Tomcat、Jetty 等容器默认启用类加载器隔离，应用自己的 WEB-INF/lib 优先于 $CATALINA_HOME/lib。但一旦配置不当，就容易出现“本地跑得好，上线就报错”。
典型错误现象：本地 IDE 启动无异常，部署到测试环境后，java.lang.ClassNotFoundException: org.apache.commons.lang3.StringUtils —— 明明 pom.xml 里有依赖，jar 也在 WEB-INF/lib 里。
- 检查 WAR 包结构：用
jar -tf your-app.war | grep lang3确认 jar 是否真被打进去；IDE 自动构建有时会跳过 scope 为runtime的依赖 - Tomcat 的
common.loader配置若强行把WEB-INF/lib加进去，会导致双亲委派被绕过，反而让应用类加载器看不到自己 jar 中的类 - Spring Boot 打成 war 部署时，要确保
spring-boot-maven-plugin没启用repackage的默认 fat-jar 行为，否则内嵌 Tomcat 逻辑会干扰外部容器类加载
OSGi 或模块化环境里 bundle 未导出/导入包
在 OSGi（如 Karaf）、Jigsaw（Java 9+ module-info.java）等模块系统中，ClassNotFoundException 往往不是“找不到类文件”，而是“找不到可访问的包”。
性能影响不大，但排查路径和传统 classpath 完全不同：它不看目录结构，只看模块声明和解析结果。
- OSGi 中用
packages:exports和packages:imports命令检查 bundle 是否真正导出目标包；常见坑是导出了com.example.api，但类实际在com.example.api.impl，而后者没导出 - Java 9+ 检查
module-info.java：调用方模块是否写了requires，被调用模块是否exports了包，且没加to限制 - 模块系统下，
Class.forName()可能抛ClassNotFoundException或ModuleResolutionException（后者更准确），但很多老框架只捕获前者，导致错误被吞掉或误判
最易被忽略的是类加载器委托链断裂 —— 比如自定义 ClassLoader 忘记调用 super.loadClass()，或者显式屏蔽了父加载器的查找结果。这种问题不会立刻暴露，但一旦遇到跨类加载器的类型转换（如 (MyService) obj），就会变成 ClassCastException，源头还是那个没加载成功的类。
