反射能绕过private访问控制，因其直接操作内存偏移量而非走语言层检查；setaccessible(true)跳过修饰符校验，但模块化下可能失败，且存在跨版本和平台兼容性问题。
反射能绕过 private，但不是“破坏封装性”的错，而是它本来就没打算替你守门。
为什么 setAccessible(true) 能读到私有字段
Java 的封装检查发生在语言层（编译期+运行时访问控制），而反射走的是 JVM 底层路径——调用 Unsafe 直接操作内存偏移量。一旦你调用 field.setAccessible(true)，JVM 就跳过修饰符校验，不看是不是 private，只认字段在对象内存里的位置。
- 这个过程不改字节码、不重加载类，纯属运行时“开后门”
-
getDeclaredField()才能拿到private字段；getField()只查public，查不到就抛NoSuchFieldException - 模块化（Java 9+）下，如果目标类在未开放的模块里，
setAccessible(true)会直接失败，抛InaccessibleObjectException
调用私有方法的三步实操和典型翻车点
想调 private void doWork(String x)？光拿到 Method 对象不够，漏掉任何一步都会报错。
- 必须用
getDeclaredMethod("doWork", String.class)——getMethod()查不到私有方法 - 必须立刻调
method.setAccessible(true)，且要在invoke()前；顺序颠倒或漏掉，报IllegalAccessException - 传参类型必须严格匹配：传
int却声明接收Integer，或参数个数不对，会抛IllegalArgumentException
示例关键行：method.invoke(obj, "hello") —— obj 不能为 null（静态方法除外），否则是 NullPointerException。
单例被反射击穿，真不是设计缺陷
很多人看到反射能 new 出第二个 ConfigManager 实例，就骂单例写得烂。其实不是。
- 单例保证的是“常规调用路径下只有一份”，不是“全宇宙绝对唯一”
- 反射 +
setAccessible(true)属于元操作，和反序列化、JNI 一样，是 JVM 提供的底层能力，框架层没法、也不该无条件拦截 - 真要防，得配合安全管理器（
SecurityManager）或模块导出限制，但生产环境极少启用SecurityManager，它早已被标记为 deprecated
真正容易被忽略的是兼容性断层：Java 17 默认开启强封装，连 --add-opens java.base/java.lang=ALL-UNNAMED 都不一定管用；而 Android 的 ART 虚拟机对 setAccessible 的行为又和 HotSpot 不完全一致。写一次反射代码，别默认它能在所有 JDK 版本和所有运行环境里安静跑完。
