理解Array.concat合并大量小数组的内存分配压力

Array.prototype.concat 在合并大量小数组时，看似轻量，实则容易引发不可忽视的临时内存压力——关键不在“大”，而在“多”和“频”。它每次调用都会创建一个全新数组，并一次性预分配足够容纳所有输入元素的空间。当面对成百上千个小数组（比如每个长度 2–10）连续 concat 时，引擎无法复用中间内存，反而会高频次地申请、填充、丢弃短生命周期数组，导致垃圾回收（GC）频繁触发，拖慢整体性能。

为什么“小数组多”比“单个大数组”更危险

单次 concat 大数组虽消耗内存，但行为可预期；而大量小数组 concat 的问题在于累积效应和碎片化：

• 每次调用都新建数组：哪怕只拼两个长度为 3 的数组，concat 也要分配一个长度为 6 的新数组，写入 6 个值，然后旧数组（若无引用）等待 GC —— 这个过程重复上千次，就是上千次小内存块分配与释放。
• 引擎难以优化连续小分配：V8 等引擎对批量大内存有优化（如预估容量、内存池复用），但对高频小数组 concat 往往按“普通对象分配”处理，易产生堆内存碎片。
• 链式调用放大开销：如 a.concat(b).concat(c).concat(d)，会生成 a+b、(a+b)+c、((a+b)+c)+d 三个中间数组，而实际只需要最终结果 —— 中间数组完全多余。

典型高风险场景识别

以下模式容易踩坑，尤其在构建工具、日志聚合、分片数据组装等逻辑中常见：

• 循环中反复调用 result = result.concat(chunk)（即累加式拼接）。
• 从 Map/Set 或多个 Promise.all 结果中逐个提取数组再 concat。
• 模板渲染层将数十个组件的 classList 数组（如 [‘btn’, ‘primary’]）逐一 concat 成最终 className 字符串数组。

更轻量的替代方案

目标不是“不用 concat”，而是避免它在高频、小粒度场景下的滥用。推荐按需选用：

• 用 Array.from + flatMap 替代链式 concat：如把 [a, b, c].map(x => x).flat() 改为 Array.from({ length: totalLen }, (_, i) => /* 按索引查对应数组 */)，或直接 [a, b, c].flatMap(x => x) —— flatMap 内部不建中间数组，且现代引擎对其做了专门优化。
• 预先收集再单次 concat：把所有待拼小数组先 push 到一个数组里，最后调用一次 allChunks.concat(…)，把 N 次分配压成 1 次。
• 用 for 循环 + push 手动摊平：对性能敏感路径，显式遍历各小数组并 push 到目标数组，内存增长线性可控，无额外中间对象。

本质上，concat 是为“明确、有限、结构清晰”的合并设计的；把它当作流式拼接积木，就容易低估背后的分配成本。观察你的调用频次和输入规模，比单纯看单次数组大小更能判断风险。