String不可变由private、final class和防御性拷贝三重保障，非仅靠final；其不可变性支撑常量池共享、HashMap哈希缓存等机制，但敏感信息需用char[]以便及时擦除。
String不可变不是靠final关键字单点保障
很多人看到private final char[] value就以为“final数组 = 内容不可变”，这是典型误解。final只锁住value这个引用不能指向别处，但完全挡不住对value[0]这种元素的直接修改——JDK源码里早有类似Array.set(value, 0, 'X')的反射绕过案例。真正让String稳如磐石的是三重封印：private彻底隔绝外部访问、final class禁止继承篡改、所有方法（concat、substring、replace）全部返回新对象而非修改原数组。构造时还偷偷做了一次Arrays.copyOf防御性拷贝，连你传进来的char[]都被复制走，原数组再怎么改都伤不到它。
常量池和HashMap依赖的是“内容终身不变”这个契约
如果String可变，String a = "hello"; String b = "hello";本该共享同一对象（a == b为true），但一旦a被意外改写成"hellx"，b读出来的就变成错的了——常量池机制直接崩盘。同理，HashMap把String当key时，hashCode()值在构造时就缓存进hash字段，后续反复用。要是字符串能改，哈希值就得每次重新算，性能暴跌不说，更致命的是：key内容变了，get()可能再也找不到原来存进去的value。
拼接字符串时频繁创建对象，不是设计缺陷而是权衡取舍
写for循环用+拼接10万条日志？会生成海量中间String对象，GC压力陡增。这不是String设计错了，而是明确告诉你：“这个场景你不该用String”。此时必须切到StringBuilder——它内部用可变char[]，append()全程复用同一块内存。但注意：StringBuilder不能跨线程共享，也不适合当Map key或配置项；而String一旦构造完成，就自动获得线程安全、可缓存、可共享等红利。选哪个，看你的数据生命周期和使用上下文。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
敏感信息不用String存储，恰恰是因为它太不可变了
密码、token这类需要快速擦除的数据，反而要避开String。因为不可变意味着：哪怕你把引用置为null，原始字符数组仍留在堆里，直到GC回收——期间可能被内存dump抓取。正确做法是用char[]接收，用完立刻循环覆写：Arrays.fill(pwd, '\u0000')。这反向印证了String不可变性的双面性：它保住了安全边界，也锁死了清除路径。
立即学习“Java免费学习笔记（深入）”；
真正难的不是记住“String不可变”，而是理解每处不可变背后绑定的具体约束条件——常量池要它不变，HashMap要它不变，类加载器要它不变。一旦脱离这些上下文谈“为什么不可变”，就容易陷入语法细节的迷宫。
