Java 模块系统拆分后反射访问为什么被拒绝

Java 项目从 classpath 拆到 JPMS 模块后，setAccessible(true) 仍可能抛出 InaccessibleObjectException。根因通常不是“反射不能用了”，而是被访问的包没有向调用方模块打开：exports 解决的是可见 API，opens 才负责深度反射。先确定调用方模块和目标包，再决定是补一个定向 opens，还是修正启动参数，别一上来把整个模块改成 open module。

Java 模块反射失败先看哪一层

排查时先看异常中提到的源模块、包名和调用方。若代码只是调用目标包中的 public 方法，重点是调用方是否读取了目标模块、目标包是否 exports；若框架要访问私有字段、非公开构造器或调用 setAccessible，重点就变成目标包是否对该框架模块 opens。

下面这段代码故意访问私有字段。它可以说明反射动作本身没有变化，但模块封装会在最后一道权限检查处拒绝请求：

Field field = UserRecord.class.getDeclaredField("tenantId");
// 触发深度反射检查；没有 opens 时可能抛出 InaccessibleObjectException
field.setAccessible(true);
String tenantId = (String) field.get(record);

不要只根据“类是 public”下结论。类的可见性、包的模块导出、私有成员的深度反射，是三层不同的边界。

exports 和 opens 的权限边界怎么区分

可以把 exports 理解成“允许其他模块正常使用公开 API”，把 opens 理解成“允许指定模块在运行时深入检查这个包”。普通模块对外没有声明的包，既不能作为稳定 API 使用，也不能接受来自其他模块的深度反射。

配置示例可以写成：

module user.domain {
    // 给正常业务调用的公开 API
    exports com.example.api;
    // 只给框架模块做运行时深度反射
    opens com.example.model to framework.core;
}

如果框架实际运行在未命名模块或 classpath 上，目标名称可能不是你看到的框架产品名。应先确认它的模块名；对未命名模块使用启动参数时，目标可以写成 ALL-UNNAMED，但范围要尽量限定到一个包。

生产环境应该怎样收窄反射范围

修复顺序建议是：先确认需要反射的具体包，再确认唯一调用方，最后选择静态声明或启动参数。能写进 module-info.java 的优先写入模块描述符；只有第三方部署方式无法修改时，才使用：

# 仅向 framework.core 打开模型包，避免打开整个 user.domain
java --add-opens user.domain/com.example.model=framework.core \
     --module-path mods \
     --module framework.launcher/com.example.Main

临时使用 --add-opens ...=ALL-UNNAMED 能快速验证假设，但它会把权限扩大到所有 classpath 代码。验证通过后，应回收为 qualified opens，并把参数从脚本、容器启动清单和测试环境逐处比对。

如果框架只需要一个受控入口，也可以让目标模块提供显式适配器，减少对私有字段的依赖。日志至少记录反射框架、目标包、部署参数来源和回归用例；这样下一次拆模块时，能区分“权限没开”与“框架假设了旧 classpath 行为”。

常见问题

只加 exports 后为什么仍然不能访问 private 字段？

exports 只解决公开 API 的模块访问；访问私有字段需要目标包对调用方 opens，或改为显式公开的适配接口。

什么时候可以使用 open module？

只有模块内大多数包都确实需要运行时深度反射、且能接受封装边界整体放宽时才考虑。业务模块通常更适合逐包、逐模块 qualified opens。

如何确认启动参数中的目标模块名？

查看依赖模块的模块描述符或构建产物元数据，确认名称后再写 --add-opens；不要用产品简称猜模块名。

这类问题的关键不是让反射“重新变得强大”，而是把访问意图说清楚：公开调用走 exports，框架深度反射走最小范围的 opens，临时参数只用于验证并最终回收到可审计的模块声明。