Class.forName()在模块化环境中失败的根本原因是模块系统限制类可见性，需确保目标模块导出包、调用方模块声明requires依赖，并使用模块感知的类加载器；否则即使类存在也会抛ClassNotFoundException。

模块化环境下用 class.forname() 加载类失败，核心问题不是方法本身出错，而是模块系统（java 9+ 的 module system）对类可见性、包导出和类加载器协作做了严格限制。默认情况下，即使类存在，若所在模块未导出对应包，或调用方模块未声明对其依赖，class.forname() 就会抛 classnotfoundexception —— 这和传统 classpath 环境下的“找不到类”表现相似，但根源完全不同。

确认模块是否导出目标包

Java 模块默认不导出任何包。如果目标类在模块 com.example.lib 中，而它的包是 com.example.service，那么必须在该模块的 module-info.java 中显式导出：

• exports com.example.service;
• 若需被反射访问（包括 Class.forName()），还建议加上 opens（尤其涉及私有成员反射时）：opens com.example.service;

未导出 = 模块外不可见，哪怕类文件物理存在，Class.forName() 也查不到。

检查调用方模块是否声明了 requires

使用 Class.forName() 的代码所在模块，必须在自己的 module-info.java 中声明对目标模块的依赖：

• requires com.example.lib;
• 如果只是编译期需要、运行时可能不存在，可用 requires static；但动态加载场景一般需直接 requires

缺少 requires 声明，JVM 在模块解析阶段就会拒绝链接，反射调用自然失败。

避免跨模块使用上下文类加载器陷阱

模块化后，不同模块可能由不同类加载器（如 ModuleLayer.boot().findLoader(...)）管理。默认 Class.forName(String) 使用当前类的类加载器，它通常只看到本模块及 requires 的模块 —— 但若目标类在未声明依赖的模块中，或通过自定义类加载器加载，就容易失败。

稳妥做法是显式指定模块感知的类加载器：

• 获取目标模块的类加载器：ClassLoader loader = ModuleLayer.boot().findModule("com.example.lib").get().getClassLoader();
• 再调用：Class.forName("com.example.service.MyService", true, loader);

注意：不能直接用 Thread.currentThread().getContextClassLoader()，它在模块化应用中往往不携带模块上下文。

区分 ClassNotFoundException 和 IllegalAccessError

模块化下常见混淆：类能成功加载（Class.forName() 不抛异常），但在后续反射调用（如 newInstance() 或 getMethod()）时抛 IllegalAccessError 或 InaccessibleObjectException。

这说明类加载成功，但访问被模块系统拦截。此时应检查：

• 目标模块是否 opens 对应包（不只是 exports）
• 是否在 JVM 启动参数中添加了必要开放指令，例如：--add-opens com.example.lib/com.example.service=ALL-UNNAMED
• 若用的是 JDK 17+，默认强封装更严，--add-opens 几乎成为反射必需项

这类错误不是 Class.forName() 的问题，但常被误判为加载失败。