JavaScript字符串不可变，即每次操作都生成新字符串而非修改原值，导致内存中堆积大量中间字符串、GC压力增大、拼接时间复杂度升至O(n²)，但换来线程安全、哈希稳定与引擎优化等核心收益。
JavaScript 字符串不可变，意味着每次修改（拼接、截取、替换等）都不会改动原字符串，而是创建一个新字符串，原字符串仍留在内存中，直到被垃圾回收。这种设计直接带来内存和性能上的连锁反应。
内存持续增长：中间字符串大量堆积
比如循环中反复用 += 拼接：
- 第一次：
s = "a"→ 内存分配 1 字节 - 第二次：
s += "b"→ 创建新字符串"ab"（2 字节），旧"a"暂未回收 - 第 n 次：已产生 n 个不同长度的字符串实例，总内存占用接近 O(n²)
当循环百万次，尤其拼接较长内容时，可能瞬间占用数百 MB 堆内存，触发频繁 GC，造成卡顿甚至崩溃。
时间开销放大：操作复杂度非线性上升
以拼接为例：
-
+或concat()：单次拼接需复制前序全部内容，n 次循环总耗时为 O(n²) -
Array.join()：先收集片段，最后一次性合并，总耗时稳定在 O(n) - 模板字面量（
`${a}${b}`）：引擎可优化为单次构建，适合固定结构拼接
实际测试中，10 万次拼接，+= 可能比 join() 慢 10 倍以上，且内存峰值高出数倍。
隐性风险：引用残留与内存泄漏
不可变性本身不导致泄漏，但开发中容易忽视引用关系：
- 把拼接过程中的中间字符串意外保留在闭包、全局对象或缓存中
- 长生命周期对象持有短命字符串（如日志模块缓存原始请求体 + 拼接结果）
- 使用
new String("...")创建包装对象，它不参与字符串常量池，且引用不易释放
这类情况会让本该被回收的字符串长期驻留堆内存，表现为内存占用只升不降。
为什么坚持不可变？权衡背后的收益
这不是缺陷，而是有意为之的设计取舍：
- 多处读取同一字符串（如 Map 键、正则匹配源）完全安全，无需加锁或深拷贝
- 引擎可复用相同字面量（如多个
"loading"共享同一内存块） - 哈希计算一次即可固化，保障
Map和Set的键稳定性 - 使内联缓存、字符串切片零拷贝等底层优化成为可能
不可变性让字符串行为可预测、线程友好、利于引擎深度优化——代价是开发者需主动避开低效模式。
