反射可静默修改String的value数组，导致常量池污染、hashCode缓存失效、HashMap/HashSet行为异常及安全假设崩塌，属未定义行为。
![java中如果通过反射强行修改 string 底层的 char[] value 会发生什么](https://img.php.cn/upload/article/001/242/473/179150154257381.png)
会静默改变字符串内容，但破坏多项关键保障，引发不可预知的运行时问题。
常量池中所有相同字面量全部被污染
Java 字符串常量池依赖“内容不变”才能安全复用。一旦通过反射修改某个 String 实例的 value 数组，所有指向同一常量池对象的引用都会看到变化后的值。
- 例如：
String a = "hello"; String b = "hello";→a == b为 true - 反射改掉
a的value[0] = 'H'后，b的内容也变成"Hello" - 日志、配置、SQL 拼接等场景可能突然输出错误内容，排查极难
hashCode 缓存失效，HashMap/HashSet 行为异常
String 的 hash 字段是懒计算且不校验的。修改 value 后，原缓存的 hash 值不再匹配新内容，但不会自动重算。
- 作为 key 存入 HashMap 的 String 被反射修改后，
map.get()可能返回 null（找不到） - 同一个字符串在 HashSet 中可能重复添加（因 hash 不一致导致误判为不同元素）
- 这种错乱不是抛异常，而是静默逻辑错误，上线后才暴露
破坏 JVM 和类库的底层假设，风险不可控
从 JDK 自身到各类框架（如 Spring、Log4j、Jackson），都默认 String 是不可变的。反射绕过 final 并非“功能”，而是突破语言契约的非常规操作。
立即学习“Java免费学习笔记（深入）”；
- 某些 JVM 优化（如字符串压缩、内联缓存）可能崩溃或产生未定义行为
- JDK 9+ 使用
byte[] + coder，反射若未正确处理 coder 字段，还会导致乱码或数组越界 - 安全敏感场景（如权限标识、token 校验）一旦被篡改，等于绕过访问控制
它不创建新对象，但也不被任何机制保护
常规字符串操作（concat、replace）都返回新实例，旧对象不受影响；而反射修改是直接覆写堆内存中的数组元素。
- 没有 GC 开销，也没有线程同步开销——但这恰恰是危险所在
- 多线程环境下，一个线程改了，其他线程立即看到脏数据，无任何提示
-
equals()仍返回 true（因为比的是当前字符），但语义已错乱
