JDK 17+ 模块化限制反射访问，需用 --add-opens 显式授权，如 --add-opens java.base/java.util=ALL-UNNAMED；升级适配 JDK 17+ 的框架版本可减少依赖；避免业务代码手动 setAccessible。
这个问题本质是 JDK 模块化系统（JPMS）对反射访问施加了严格限制，不是代码有 bug，而是 JVM 主动拦截了原本在 JDK 8 下被允许的“深度反射”行为。关键在于：模块默认不开放私有成员的反射入口，setAccessible(true) 在 JDK 17+ 不再自动生效，必须显式授权。
看懂错误堆栈，定位具体被拦的包和模块
报错信息里藏着修复线索。例如：
Unable to make field private java.util.ArrayList.elementData accessible: module java.base does not "opens java.util" to unnamed module
这行话明确告诉你三件事：
- 想访问的是 java.util.ArrayList 的私有字段 elementData
- 这个类在 java.base 模块里
- 你的应用运行在未命名模块（unnamed module），而 java.base 没有向它开放 java.util 包
所以第一步永远是复制报错中 “module XXX does not 'opens YYY'” 这部分，提取出源模块名（如 java.base）和目标包名（如 java.util）。
用 --add-opens 精准放开，不滥用 ALL-UNNAMED
在 JVM 启动时添加参数，格式固定为：--add-opens 源模块/包=目标模块。
- 开发或测试环境常用写法：--add-opens java.base/java.util=ALL-UNNAMED
- 生产环境更推荐指定你自己的模块名（如果用了 module-info.java）：--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-opens java.base/java.time=ALL-UNNAMED
注意：--add-modules ALL-SYSTEM 完全无效，它只加载模块，不解决反射权限问题。
检查框架和依赖是否已适配新 JDK
很多老版本库（如 Groovy 2.4、Lombok 1.18.20 之前、MyBatis-Plus 3.4.3 之前）内部硬编码了反射调用，没做模块兼容处理。
- 升级 Spring Boot 到 3.1+（原生支持 JDK 17+ 模块化）
- 将 MyBatis-Plus 升级到 3.5.3+，它已改用更安全的字段访问策略
- 若项目依赖 ShardingSphere 或 Feign，确认其版本是否声明支持 JDK 17（通常需 5.3.0+ 或 12.0+）
升级后，部分 --add-opens 参数可能就不再需要了。
避免在业务代码里手动 setAccessible
除非是测试或框架开发，否则不要在你自己写的 Service 或 Controller 里写 field.setAccessible(true)。
- 它在 JDK 16+ 默认直接失败，且违反封装原则
- 如果确实要动态操作字段，优先考虑使用标准 API（如 BeanUtils.copyProperties）或 Jackson 的 @JsonCreator/@JsonProperty
- 若必须用反射，请确保目标类字段是 public 或提供标准 getter/setter
真正该用反射的地方，比如 ORM 映射、序列化、AOP 增强，都应交给成熟框架处理——它们比你自己写的反射更健壮、更兼容模块化。
