String不可变是设计契约而非JVM强制，反射可修改但属高危操作；其通过final类、private final底层数组、所有方法返回新对象三层保障常规不可变性。
不违背。Java 中 String 的“不可变”是一种设计契约和逻辑保障，不是 JVM 层面的强制安全锁。反射能改，恰恰说明它本就不该被当作防篡改的盾牌。
不可变的三层防护是给人用的，不是给反射拦的
String 类通过三重机制实现日常使用的不可变性：
- final class：禁止继承，避免子类重写方法破坏行为
- private final char[] / byte[] value：字段私有 + 引用不可重赋，外部无法直接访问或替换底层数组
- 所有 public 方法都返回新对象：replace、concat、substring 等操作不修改原实例，而是 new 一个 String
反射绕过的是语言层访问控制，不是设计失效
反射调用 setAccessible(true) 是在主动打破封装边界，属于 Java 提供的底层调试/框架能力，类似用螺丝刀拆开手机后盖——能拆不等于手机设计错了。
- 它跳过了 private 限制，拿到了 value 字段的引用
- 它没新建对象，而是直接修改了原数组元素（如
array[0] = 'X'） - 这导致常量池污染、hashCode 缓存错乱、安全校验失灵等真实风险
真正的问题不在“能不能”，而在“该不该”
不可变性的价值体现在常规使用场景中：
立即学习“Java免费学习笔记（深入）”；
- 字符串字面量可安全共享（
"abc" == "abc"） - 多线程下无需同步（天然线程安全）
- HashMap 的 key 可靠（hash 值稳定，equals/hashCode 一致）
- 类加载、权限检查依赖内容稳定（如
System.getProperty("java.home")）
这些好处在没人用反射乱动的前提下全部成立。一旦反射介入，就已脱离“正常编程模型”，进入高危操作区。
开发中要守住的底线
- 生产代码禁用对
String.class的setAccessible(true) - 敏感数据（密码、token、路径）不用 String，改用
char[]并及时清空 - 单元测试若需反射验证内部状态，确保仅限测试 scope，不进主流程
- 理解
final的真实语义：它锁引用，不锁内容；锁可见性，不锁底层内存
