根本原因是模块系统或运行时环境限制：jdk 9+ 模块封装、android art 隐藏 api 限制、jdk 16+ --illegal-access=deny 等机制使 setaccessible(true) 失效，而非未调用该方法。
为什么调用 setAccessible(true) 后还是抛 IllegalAccessException
根本原因不是没调 setAccessible(true)，而是它被 SecurityManager 拦住了，或者运行在强约束环境（如 JDK 12+ 的默认模块封装下）。JDK 9 引入模块系统后，即使设了 setAccessible(true)，跨模块访问私有成员仍可能失败——这不是反射 API 失效，是模块访问控制在起作用。
常见错误现象：IllegalAccessException: class X cannot access a member of class Y with modifiers "private"，哪怕你明确写了 method.setAccessible(true)。
- 检查是否在 modular JVM（JDK 9+）中运行，且目标类不在同一模块或未导出/开放包
- 确认没有启用
SecurityManager（已弃用但某些老容器仍可能激活） - 如果是单元测试，注意测试类和被测类是否属于不同命名模块（
module-info.java中未声明opens）
JDK 9+ 跨模块调用私有方法必须加 opens 声明
模块系统默认禁止反射穿透，setAccessible(true) 只能绕过 Java 语言层的访问检查，不能绕过模块系统的封装策略。要让反射生效，必须在 module-info.java 中显式开放包：
module my.app {
opens com.example.internal to java.base;
}
说明：
立即学习“Java免费学习笔记（深入）”；
-
opens是必须的，exports不够（后者只对 public 成员有效） -
to java.base表示只允许java.base模块（含java.lang.reflect）反射访问；若用其他框架（如 Spring），需写成to spring.core - 如果目标类在 unnamed module（比如 classpath 启动），此限制不触发，但 JDK 17+ 默认禁用 classpath 启动方式
Android 上 setAccessible(true) 失效的真正原因
Android Runtime（ART）从 Android 9（Pie）开始默认屏蔽反射修改私有成员，不是因为没设 setAccessible(true)，而是底层直接拒绝执行。Logcat 里常看到：Accessing hidden method L...;->methodName()V (greylist-max-o) 或直接 crash。
- 无法通过
setAccessible(true)绕过，这是运行时强制策略，非 SecurityManager 逻辑 - 替代方案：改用
JavaAgent（不适用于普通 App）、或用官方支持的 API（如View.setAccessibilityDelegate替代反射改mAccessibilityDelegate） - Debug 构建中可通过
hiddenapi-policy=just-warn降级提示，但上线包无效
生产环境慎用 setAccessible(true) 的三个硬约束
它不只是“不推荐”，而是会在特定条件下彻底失效或引发不可控行为：
- JDK 16+ 启用
--illegal-access=deny（默认）后，对 JDK 内部类（如sun.misc.Unsafe）的反射会直接抛InaccessibleObjectException，不是IllegalAccessException - GraalVM Native Image 编译时会静态裁剪所有未显式注册的反射目标，
setAccessible(true)在 native 模式下完全无意义 - 某些安全加固的 JVM（如 Alibaba Dragonwell 的 security mode）会全局拦截
setAccessible调用，返回 false 或静默失败
真要绕过访问控制，得先确认运行时环境是否允许——而不是只盯着有没有调那行代码。
