Class.forName抛出ClassNotFoundException的本质是JVM运行时无法在classpath中定位指定类，需从类存在性、路径正确性、名称准确性及加载器可见性四方面排查。
Class.forName 在类未找到时抛出 ClassNotFoundException，本质是 JVM 无法在类路径（classpath）中定位到指定的类名。这不是代码逻辑错误，而是运行时环境配置或类名使用不当导致的问题。解决方向集中在确认类存在、路径正确、名称准确、加载时机合理这四点上。
确认类名拼写和包路径完全正确
这是最常见的原因。Class.forName 接收的是**全限定类名（Fully Qualified Name）**，必须包含完整包路径，且大小写严格匹配。
- 错误写法：
Class.forName("userdao")或Class.forName("UserDao")（缺少包名） - 正确写法：
Class.forName("com.example.dao.UserDao") - 注意：内部类要用
$分隔，如com.example.Outer$Inner，不能用点号
检查类是否真正在 classpath 中可用
编译通过不代表运行时能加载。需确认该类的 .class 文件或所在 JAR 已被加入运行时 classpath。
- IDE 中：检查模块依赖、Libraries 设置，确保对应 JAR 或 source folder 已参与构建和运行
- 命令行启动时：用
-cp或-classpath显式指定所有依赖路径，例如：java -cp "lib/my-dao.jar:." MyApp - Web 应用（如 Tomcat）：确认 JAR 放在
WEB-INF/lib/，类文件放在WEB-INF/classes/对应包目录下
区分编译期引用与运行时动态加载
如果类只在 Class.forName 中使用，而源码里没有直接 import 或 new 实例，编译器不会报错，但运行时会失败——此时要特别验证该类是否真的被打包进最终产物。
立即学习“Java免费学习笔记（深入）”；
- Maven 项目：检查
target/classes或生成的 WAR/JAR 中是否存在对应路径的 .class 文件 - 使用
jar -tf your-app.jar | grep UserDao快速验证 - 避免“假依赖”：某些依赖可能仅在 test scope，未打入生产包
考虑类加载器隔离问题（尤其在容器或模块化环境）
在 OSGi、Spring Boot Fat Jar、应用服务器（如 WebLogic）等环境中，类加载器层级不同，可能导致父加载器找不到子上下文中的类。
- 可显式传入当前线程上下文类加载器：
Class.forName("com.example.Service", true, Thread.currentThread().getContextClassLoader()) - Spring 环境中，优先使用
ClassUtils.forName()，它自动适配上下文类加载器 - 模块化 Java（Java 9+）需确保目标模块已导出（exports）该包，并在 module-info.java 中声明 requires
不复杂但容易忽略，关键在于把“类在哪”和“JVM 能否看到它”分开验证。先打印 classpath、再查类文件位置、最后核对全名，通常就能定位根源。
