ClassNotFoundException是受检异常，因动态加载时类路径缺失、类名错误、类加载器隔离或打包遗漏导致，需检查类名匹配、依赖引入、JAR内容及上下文类加载器。

直接改代码本身通常解决不了 ClassNotFoundException，因为它不是语法或逻辑错误，而是运行时环境问题——JVM 在指定路径里压根没找到你要的那个类。关键要定位“为什么找不到”，再针对性修复。

检查类名和包路径是否完全匹配

这是最常见也最容易忽略的原因。Java 对大小写、拼写、点号分隔符极其敏感。

• 确认你传给 Class.forName("xxx") 或 loadClass("xxx") 的字符串，和实际类文件的全限定名（包括包名）一字不差
• 比如类在 src/main/java/com/example/MyService.java，编译后应为 com.example.MyService，不能写成 com.example.myservice 或 com.example.MyServiceImpl
• Kotlin 生成的伴生对象类名是 MyClass$Companion，反射时需注意

确认类确实存在于运行时 classpath 或 module path

编译通过 ≠ 运行时可用。重点看打包和部署环节：

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

• Maven/Gradle 项目：运行 mvn dependency:tree 或 ./gradlew dependencies，确认目标类所在的依赖已正确引入，且没有被 excluded 或版本冲突覆盖
• JAR 包运行：用 jar -tf your-app.jar | grep TargetClass 检查类是否被打进最终包里
• Web 应用（如 Tomcat）：确保 JAR 放在 WEB-INF/lib/（应用级）或 $CATALINA_HOME/lib/（全局级），不要混放
• 模块化项目（JPMS）：如果用了 module-info.java，需用 requires 显式声明依赖，并确认目标类所在模块已导出（exports）

排查动态加载逻辑是否用了错误的类加载器

自定义类加载、插件、热部署等场景中，加载器层级错位是高频原因。

立即学习“Java免费学习笔记（深入）”；

• 避免直接调用 ClassLoader.getSystemClassLoader().loadClass(...) 加载应用类——系统类加载器看不到你的应用类路径
• 在 Servlet 或 Spring 环境中，优先使用当前线程上下文类加载器：Thread.currentThread().getContextClassLoader().loadClass(...)
• Android 插件开发中，DexClassLoader 构造时第二个参数（parent）不能为 null，应传入宿主的 ClassLoader

留意构建与混淆带来的“隐形消失”

尤其在 Android 或启用代码优化的 Java 项目中：

• ProGuard/R8 混淆可能把反射用到的类整个移除，需加保留规则：-keep class com.example.** { *; }
• MultiDex 配置缺失（Android 5.0 以下）会导致部分类无法加载，需确认 MultiDex.install(this) 调用时机正确
• IDE 编译输出目录（如 target/classes 或 out/production）是否包含该类？清理并重新构建项目常能暴露遗漏