push到空数组本身不危险，真正性能瓶颈在于后续使用方式：频繁扩容导致内存抖动、展开运算符触发栈溢出、稀疏结构引发o(length)遍历及gc压力；应依场景选用concat、分块push或预分配typedarray等优化策略。
在大规模数据处理中，push 到空数组本身并不危险，真正引发性能问题的是后续的使用方式——尤其是配合展开运算符（...）、apply 或循环中反复调用 push 时，触发的底层内存分配抖动、参数栈溢出与稀疏结构残留。
一、push 到空数组为何可能变慢？
看似“从零开始”，实则引擎需为数组预估容量。V8 等引擎对空数组首次 push 会分配小缓冲区（如 4 或 16 项），后续每次扩容按约 1.125 倍增长。当一次性追加数十万元素：
- 频繁触发小规模内存重分配 + 元素拷贝，产生大量碎片
- 若用
target.push(...hugeArray)，引擎仍需将每个元素压栈，超过 ~65536 参数上限即报RangeError - 即使改用
for循环逐个push，虽避开了栈溢出，但写放大效应明显（尤其在低内存设备或 Web Worker 中）
二、比“慢”更隐蔽的风险：稀疏数组与 GC 压力
某些 push 模式会导致数组内部结构稀疏，比如在非连续索引位置插入、或中间有 undefined 占位。此时：
-
arr.length很大，但Object.keys(arr).length很小，引擎无法紧凑压缩内存 -
map、filter等遍历操作仍需扫描全部索引空间，时间复杂度退化为 O(length)，而非 O(有效元素数) - 旧数组未及时回收，新数组又已分配，堆内存瞬时翻倍，触发高频 Scavenge，CPU 出现卡顿
三、更优的替代方案
根据是否允许新建数组、是否需复用原引用，选择不同策略：
- 允许新建：直接用
const result = [].concat(a, b, c)——无栈溢出风险，现代引擎深度优化，百万级合并比分块push更快 - 必须复用原数组且数据量可控（＜5 万）：可用
arr.push(...chunk)，简洁安全 - 必须复用且超大规模（＞10 万）：手动分块，例如每批 2000–5000 项，调用
arr.push(...slice)，避免单次参数超限 - 极端场景（如日志聚合、流式拼接）：考虑预分配定长数组 +
copyWithin或 TypedArray，绕过 JS 数组动态扩容机制
四、一个快速判断信号
执行一次合并后，立即检查：
-
console.log(arr.length, Object.keys(arr).length)—— 若差值巨大，说明已有稀疏隐患 - 打开 Chrome DevTools → Memory 面板 → 录制堆快照，对比前后“ArrayBuffers”和“Array”实例数量突增情况
- 在 Node.js 中加
--trace-gc --trace-gc-verbose，观察是否出现密集的Scavenge日志
