JDK 9+ 模块系统严格限制反射访问，未导出/未开放的包或成员调用 setAccessible(true) 会触发警告（JDK 9–15）或直接抛 InaccessibleObjectException（JDK 16+），需通过 --add-opens 运行时参数显式授权，如 --add-opens java.base/java.util=ALL-UNNAMED。
为什么 setAccessible(true) 在 JDK 9+ 会触发警告甚至失败
不是代码写错了，是 JVM 真的在拦你——JDK 9 引入模块系统后，java.base 等核心模块默认禁止反射穿透非导出包（比如 sun.misc.Unsafe）或非公开成员。即使调用 setAccessible(true)，也会收到 WARNING: Illegal reflective access 日志，且在 JDK 16+ 默认直接抛 InaccessibleObjectException。
根本原因不是反射本身被禁，而是模块间访问控制变严格了：一个模块没显式 opens 或 exports，你就不能通过反射碰它的类/字段/方法。
- 常见错误现象：
java.lang.reflect.InaccessibleObjectException: Unable to make field private java.util.ArrayList.elementData accessible - 典型场景：序列化框架（如 Kryo）、ORM（如 Hibernate 的字段注入）、测试工具（Mockito 字段 mock）在升级 JDK 后突然崩
- 注意：
--add-opens是运行时参数，编译期完全不检查，所以编译通过、运行报错很常见
怎么用 --add-opens 精准放开模块权限
必须在 JVM 启动时加参数，粒度到「源模块→目标包」，不能只写模块名。格式是 --add-opens 源模块/包=目标模块，比如你要反射访问 java.util.ArrayList 的私有字段，得放开 java.base/java.util 包给你的模块（或 ALL-UNNAMED）。
- 最常用写法（适用于大多数第三方库和测试）：
--add-opens java.base/java.util=ALL-UNNAMED - 如果明确知道自己的模块名（如
com.example.app），更安全：--add-opens java.base/java.util=com.example.app - 多个包要放开？重复写多条参数，不能合并：
--add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED - 别乱用
--add-modules ALL-SYSTEM，它不解决反射权限问题，纯属误导
IDE 和构建工具里怎么配才生效
很多人在代码里加了 --add-opens 却没效果，是因为只改了编译配置或 Maven 的 compilerArgs——那些参数只影响 javac，不影响 JVM 运行时。必须塞进「运行时 JVM 参数」里。
立即学习“Java免费学习笔记（深入）”；
- IntelliJ IDEA：Run → Edit Configurations → VM options 输入框里粘贴，例如：
--add-opens java.base/java.time=ALL-UNNAMED - Maven Surefire（跑测试）：
<jvmArgs>--add-opens java.base/java.lang=ALL-UNNAMED</jvmArgs>放在<configuration>下 - Gradle：
test { jvmArgs = ['--add-opens', 'java.base/java.lang=ALL-UNNAMED'] } - Spring Boot 启动 jar：直接加在命令后面，
java --add-opens ... -jar app.jar
替代方案：什么时候该放弃反射，改用其他方式
加 --add-opens 是最快解法，但长期看不健康——它把模块边界形同虚设，且 JDK 未来可能彻底移除该开关。真要稳定，优先考虑不碰私有成员。
- 用标准 API 替代：比如想读
ArrayList.size，别反射字段，用list.size()；想清空，用list.clear() - 找官方支持的扩展点：Hibernate 提供
@AccessType，Jackson 有@JsonCreator+ 全参构造器，比反射字段更可靠 - 如果是单元测试需要 mock 私有方法：用
Mockito.mockStatic()（Mockito 4+）或PowerMock（慎用，兼容性差），而不是自己写反射调用 - 模块内访问？把相关类提到同一模块，并在
module-info.java里用opens声明包：opens com.example.internal to com.example.test;
模块系统不是来添堵的，是逼你把依赖关系显式化。反射绕过封装容易，但哪天 ArrayList 内部字段重命名，或者模块策略收紧，所有 --add-opens 都得重新对一遍。
