java 9+中setaccessible(true)抛inaccessibleobjectexception是jpms模块封装限制所致，需用--add-opens显式授权，如--add-opens java.base/java.lang=all-unnamed，且必须作为jvm运行参数配置。
Java 9 引入 JPMS 后，反射机制不再能“无条件穿透”模块边界。调用 setAccessible(true) 会直接抛出 InaccessibleObjectException，这不是代码错误，而是模块系统在运行时主动拦截——必须显式授权才能通过。
模块封装限制的核心表现
默认情况下，模块只 exports 包供编译期类型访问，但不 opens 包供反射访问。即使注解加了 @Retention(RUNTIME)、字段是 private、方法有 @Override，只要所在包没被开放，getDeclaredAnnotations()、getDeclaredField()、getDeclaredMethod() 等都会失败。
-
exports解决“能不能看到这个类”，opens才解决“能不能反射读它的私有成员” - JDK 内部包（如
jdk.internal.misc、sun.misc）默认完全封闭，连Unsafe.getUnsafe()都无法反射获取 - 异常堆栈里一定包含明确提示，例如：
module java.base does not "opens java.lang" to unnamed module
突破限制的两种主要方式
根据你的项目是否已模块化，选择对应方案：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
传统 classpath 应用（未写 module-info.java）：只能靠 JVM 启动参数
--add-opens授权
格式严格：--add-opens /=，例如：--add-opens java.base/java.lang=ALL-UNNAMED--add-opens com.example.app/com.example.entity=ALL-UNNAMED
注意：ALL-UNNAMED全大写，不能写成all-unnamed；不能省略包名，java.base/ALL-UNNAMED是非法写法 -
已模块化的应用（有 module-info.java）：应在源模块中声明
opens
例如，若注解定义在com.example.annotation包中，且需被java.base的反射 API 读取，则写：opens com.example.annotation to java.base;
若调用方是另一个命名模块（如com.example.service），则写：opens com.example.annotation to com.example.service;
哪些情况容易踩坑
常见误判和配置失效原因：
- 只加了
--add-exports没加--add-opens：导出类型可见性 ≠ 开放反射权限 - 把参数加在编译命令（
javac）里，而非 JVM 运行命令（java）：该参数仅在运行时生效 - IDE 中配置了 VM options，但运行的是 JUnit 测试或 Spring Boot 启动类，未在对应 Run Configuration 里重复设置
- 多个包需要开放，却试图合并写成一条（如
--add-opens java.base/{java.lang,java.util}=ALL-UNNAMED）：必须逐条独立声明
更健壮的长期建议
硬开模块权限是过渡手段，不是设计终点：
- 优先使用标准公开 API 替代反射读私有字段，比如用
getAnnotation(Class)而非手动遍历getDeclaredAnnotations() - 框架类库（Spring、Hibernate、Jackson）应升级到明确支持 JPMS 的版本，它们内部已改用服务加载或预注册机制
- 自定义注解尽量避免放在
private字段上；改用构造器注入或公开 getter 方法携带元数据 - 安全敏感模块应严格控制
opens范围，只对可信调用方开放，而非一律指向ALL-UNNAMED
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
