频繁用加号拼接字符串会快速制造大量短命对象，因字符串不可变性迫使每次拼接都新建对象，Java中产生废弃String和StringBuilder，JavaScript中触发高频GC与内存峰值O(n²)增长。
频繁用加号拼接字符串会快速制造大量短命对象，不是因为内存不够，而是对象诞生速度远超垃圾回收清扫能力。这在Java和JavaScript中表现不同，但底层逻辑一致：字符串不可变性迫使每次拼接都得新建对象，旧对象立即失效，变成“临时碎块”。
为什么+拼接会产生成堆临时碎块
Java里String是final char[]（JDK9+为byte[]），内容无法修改。写s += "x"时，JVM实际执行：
→ 新建StringBuilder
→ append原字符串 + 新内容
→ toString()生成新String
→ 原String和中间StringBuilder全部丢弃
循环1000次，就产生1000个废弃String + 1000个废弃StringBuilder，全进年轻代Eden区。Minor GC虽快，但应用线程分配对象是纳秒级，GC线程根本追不上——结果就是Eden反复打满、GC停顿频发、CPU空转扫地。
JavaScript同理。V8引擎下，str += "a"每次都要：分配新内存 → 复制原内容 → 追加 → 释放旧内存。10万次拼接可能触发上千次GC暂停，内存峰值呈O(n²)增长，中间副本总量轻松破500MB。
V8的扁平字符串优化如何缓解这个问题
V8并非靠“让字符串可变”来解题，而是通过**惰性扁平化（Lazy Flattening）** 和**字符串切片共享**，把很多本该复制的操作变成指针引用：
- 当两个字符串拼接时，V8先不拷贝，而是创建一个ConsString（连接节点），内部只存两个子串的引用
- 只有真正需要读取内容（比如
.length、.charAt()或传给DOM）时，才触发扁平化：递归展开所有ConsString，合并成一个连续内存块 - 若拼接的是小字符串或已知长度，V8还会预分配精确空间，避免多次扩容
- 模板字符串（
`${a}${b}`）更进一步：引擎在解析阶段就计算总长、预分配内存、直接写入，跳过中间对象
哪些写法依然会绕过优化、照旧产垃圾
V8再聪明，也救不了某些硬编码习惯：
-
循环内反复
+=：即使有ConsString，深度嵌套也会导致扁平化开销剧增，最终仍要一次性合并大块内存 - 拼接超大字符串（如2MB日志行）：V8会判定为大对象，跳过新生代，直入老生代；Mark-Sweep回收慢、易碎片，卡顿明显
-
隐式拼接未关闭的日志：
log.info("id=" + user.id)哪怕日志级别设为ERROR，拼接照样执行，对象照造 -
滥用
String.prototype.concat()：比+还慢20–40%，且不享受模板字面量的预编译优势
真正靠谱的写法不是“选哪个语法”，而是“别让它发生”
高性能拼接的关键不在语法糖，而在控制对象生命周期：
- 小量拼接（几十次以内）：放心用
+或模板字符串，现代引擎已足够快 - 大批量动态拼接（万次以上）：改用
parts.push(x); parts.join('')，时间/空间复杂度都是O(n) - 日志类场景：一律用占位符
log.info("user={}, time={}", id, ts)，参数延迟求值 - 超大文本流（如导出CSV）：放弃全量拼接，改为逐行写入文件或响应流，内存恒定
