加号操作符比concat()更高效，因V8等引擎对a + b + c有编译期优化和内存预估，而concat()需函数调用开销及产生中间字符串；海量文本应改用join()或流式处理。
在处理海量原始文本时，
和加号操作符（
）的性能差异并不像很多人想象的那样显著——现代 JavaScript 引擎（V8、SpiderMonkey、JavaScriptCore）对字符串拼接已做了深度优化，**二者在大多数实际场景中性能接近，甚至加号更稳定**。关键不在“用哪个”，而在“怎么用”。
引擎优化让加号操作符更高效
V8 等主流引擎对连续的
表达式（如
）会进行编译期合并与内存预估，直接生成最优的字符串构建逻辑；而
是一个函数调用，存在额外的栈开销和参数解析成本。尤其在链式拼接（如
）时，会产生中间字符串对象，反而不利于 GC。
✅ 推荐写法：
（静态可预测长度）
❌ 低效写法：
真正影响性能的是拼接模式，不是语法选择
当文本量达 MB 级或需循环拼接数千次以上时，瓶颈从来不是
或
的微小差异，而是**字符串不可变性导致的重复内存分配**。
⚠️ 危险模式：在 for 循环中反复
（每次创建新字符串，O(n²) 时间复杂度）
✅ 高效替代：改用
+
，或
思路（如
后批量
）
? 小技巧：若确定最终长度，可用
预占空间（仅限简单重复场景）
压测时要注意的干扰项
真实压测容易得出误导结论，常见陷阱包括：
未启用严格模式或未关闭开发者工具（V8 会降级优化）
测试字符串过短（
未 warm-up：首次执行含解析/编译开销，应先运行数百次再计时
忽略 GC 影响：大量短生命周期字符串会触发频繁垃圾回收，应使用
（V8 内部命令）或分段压测
什么情况下该用 .concat()？
并非过时，它在特定语义场景仍有价值：
需要兼容极老环境（IE6–8），且不使用 Babel 转译时
拼接参数动态不确定（如
），但注意：ES2015+ 更推荐展开运算符
代码风格统一要求（团队规范强制用方法而非操作符），此时性能差异可忽略
不复杂但容易忽略：拼接性能的天花板取决于内存带宽与 GC 效率，而不是选
还是
。真要优化海量文本，请优先考虑流式处理、分块构建、避免全量驻留内存。
String.prototype.concat()++a + b + c.concat()s1.concat(s2).concat(s3)const result = a + b + c + d;const result = a.concat(b).concat(c).concat(d);+.concat()str += chunkArray.push().join('')StringBufferlet chunks = [];chunks.push(chunk)new Array(len).join('')%gc().concat()arr.concat(...others)[...arr, ...others].join('')+.concat()