string.concat() 和 + 运算符在现代 js 引擎中性能几乎无差别；真正影响性能的是拼接次数与字符串长度，应依场景选用 join()、模板字面量或 buffer.concat()。

String.concat() 和 + 运算符在现代 JS 中性能几乎没差别

直接说结论：String.concat() 和 + 在 V8（Chrome/Node.js）、SpiderMonkey（Firefox）、JavaScriptCore（Safari）里，对短字符串拼接的性能差异可以忽略不计。引擎早已把 + 编译为高效路径，而 concat() 也做了内联优化。你测出明显差距，大概率是测试方式有问题（比如没预热、字符串太长、混入对象隐式转换）。

真正影响性能的关键是拼接次数和字符串长度

当你要拼接几十次以上，或单次拼接涉及 KB 级字符串时，+ 和 concat() 都会因字符串不可变性触发多次内存分配。这时应该换策略：

• 大量动态拼接 → 用 Array.push() 收集再 join('')
• 模板化内容 → 直接用模板字面量 `${a}${b}${c}`（V8 对它有专门优化）
• 服务端或 Node.js 流式场景 → 用 stream.Transform 或 Buffer.concat()，别碰字符串拼接

concat() 的语义和边界行为比 + 更严格

concat() 只接受字符串参数，遇到非字符串会调用 ToString（不是 toString()），而 + 在左侧为字符串时会强制转字符串，但可能触发意外的 valueOf() 或 toString() 调用：

const obj = { toString: () => 'a', valueOf: () => 42 };
'x' + obj;        // 'x42' ← 先 valueOf()
'x'.concat(obj);  // 'xa'  ← 只走 ToString，即 toString()

所以如果你依赖明确的类型转换逻辑（比如处理用户输入后拼接日志），concat() 行为更可预测；但日常开发中，这种差异极少构成选型依据。

实际项目里该选哪个？看可读性和团队习惯

没有性能包袱的前提下：

• 两个值拼接 → 无脑用 +，最直觉，压缩工具也认得
• 多个字符串合并（且已存在数组）→ 用 arr.join('')，不是 concat()
• 需要链式调用且参数确定 → str.concat(a, b, c) 可读性略好，但多数人不这么写
• TypeScript 项目 → concat() 有更精确的重载签名，+ 是 any → string，类型检查弱一点

真正容易被忽略的是：不要为了“理论上更快”去改已有代码。V8 的 + 优化非常成熟，而 concat() 在某些老版本 Safari 上对空字符串处理有 bug（如 ''.concat(undefined) 报错），这种兼容性坑比性能差更值得警惕。