Java 模块反射访问被拒绝时怎么区分 exports 和 opens

日常使用Java 9及以上版本的模块系统时，经常会碰到反射访问目标类被拒绝的报错，这时可以先看抛出的异常描述、判断当前操作是普通公开类调用还是深度反射访问，就能快速区分对应的exports和opens配置差异。

区分两类配置可以直接对照报错信息、访问类型、作用边界三个维度：如果是编译期或者常规调用期报访问不到公开类/公开成员的错，对应缺里的exports配置；如果是运行期做非公开成员的反射访问才抛的拒绝错，对应缺opens配置。

Java 模块遇到“访问被拒绝”时，先不要急着把 exports 改成更宽的权限。判断标准很简单：调用方只需要访问公开类型或公开成员，用 exports；框架需要通过反射进入非公开成员，尤其调用 setAccessible(true) 或 privateLookupIn，用 opens。如果只是临时处理第三方库，则可以用启动参数 --add-opens，但它不应替代长期的模块声明。

先从异常和调用方式判断访问深度

同样是反射异常，修复点可能完全不同。代码只读取一个公开类，通常检查 requires 与 exports；代码通过反射访问私有字段、私有构造器或调用 setAccessible(true)，检查的就是 opens。把后者误写成 exports，即使模块能被读取，深反射仍会失败。

检查 module-info.java 的包和调用方模块

假设业务模块名为 order.core，框架模块名为 mapper.runtime。公开 DTO 可以导出，内部实体只给框架做反射时应使用限定的 opens ... to：

module order.core {
    // 对普通调用方开放稳定的公开 API
    exports com.example.order.api;

    // 只给指定框架做运行时深反射
    opens com.example.order.entity to mapper.runtime;

    // 调用方要读取本模块，还必须建立可读性
    requires mapper.runtime;
}

exports 只对公开类型和公开成员建立普通访问边界；opens 不让包在编译期变得可见，却能允许指定模块反射访问包内全部类型和成员。若框架在类路径上，调用方通常属于未命名模块，限定写法可以改为对 ALL-UNNAMED 的启动时打开。

按访问深度选择 exports、opens 或 --add-opens

可以按下面的顺序处理，而不是先全局放开：

1. 公开 API 被直接引用：在目标模块写 exports 包名，同时确认调用方 requires 目标模块。
2. 框架只需要访问公开成员：优先保持 exports，不要额外开放私有实现。
3. 框架需要私有字段或构造器：写限定的 opens 包名 to 框架模块。
4. 暂时不能修改模块声明：用精确到模块和包的参数，例如：

# 只把 order.core 的实体包打开给类路径上的框架
java --add-opens order.core/com.example.order.entity=ALL-UNNAMED -jar app.jar

--add-exports 适合补公开访问边界，不能把它当作深反射的替代品。生产环境更应记录是哪一个库需要私有访问，并优先升级库、调整映射方式或补上限定的 opens。

用 Module API 确认权限是否落在正确位置

当模块名、包名和框架调用关系较复杂时，可以在诊断代码中直接检查运行时状态。下面的代码只做权限观测，不修改模块关系：

static void printAccess(Class> target, Class> caller) {
    Module source = target.getModule();
    Module consumer = caller.getModule();
    String pkg = target.getPackageName();

    // exports 判断公开访问边界，opens 判断深反射边界
    System.out.printf("%s -> %s: exported=%s, open=%s%n",
            source.getName(), consumer.getName(),
            source.isExported(pkg, consumer),
            source.isOpen(pkg, consumer));
}

输出中 exported=true 只能说明公开边界满足，不能推出 open=true。如果两个值都为 false，检查包名是否写错、调用方实际属于哪个模块，以及限定的 to 后面是否写成了框架的真实模块名。

常见问题

有了 requires，为什么 setAccessible 仍然失败？

requires 只建立模块可读性，不授予私有成员反射权限。需要深反射时，补目标包的 opens 或精确的 --add-opens。

exports 和 opens 能不能同时写？

可以。一个包可以对外提供公开 API，同时对某个框架限定开放深反射；把两个需求分开表达，通常比把整个模块声明为 open module 更安全。

什么时候使用 open module？

只有当模块中的所有包都确实需要运行时深反射时才考虑它。业务模块通常更适合按包使用限定 opens，这样后续能清楚收回不必要的反射入口。