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) 报错），这种兼容性坑比性能差更值得警惕。
