array.prototype.push本身不会栈溢出，问题在于调用方式：配合apply或扩展运算符批量传入海量元素时，引擎需将每个元素作为独立参数压栈，超出v8等引擎约65536的参数上限即报rangeerror。
Array.prototype.push 本身不会栈溢出，问题出在**怎么调用它**——当配合 apply 或扩展运算符批量传入海量元素时，引擎需把每个元素作为独立参数压入调用栈，超出限制即崩溃。
根本原因：参数数量触达引擎硬上限
V8（Chrome/Node.js）等主流引擎对单次函数调用的参数个数有严格限制，通常在 65536 左右。这不是内存不足，而是调用栈帧数量超限。
-
arr.push.apply(arr, hugeArr)等价于arr.push(item0, item1, ..., itemN)，N 就是hugeArr.length - 若
hugeArr有 10 万项，V8 直接拒绝执行，抛出RangeError: Maximum call stack size exceeded - Firefox（SpiderMonkey）限制略低，约 5 万；Safari（JavaScriptCore）也类似，均非无限
扩展运算符 ≠ 安全替代，本质相同
arr.push(...hugeArr) 看似现代简洁，但底层仍走 apply 路线：引擎仍需展开 hugeArr 每一项为参数。它不是“语法糖优化”，而是“语法糖陷阱”。
- 不是浏览器版本新就更安全，而是机制未变
- 只要
hugeArr.length > 引擎参数上限，必报错，与写法无关 - 哪怕只差 1 项（比如 65537），也会失败
真正可行的边界控制策略
不靠猜测，而靠分块——把大数组切成若干子段，每段长度 ≤ 安全阈值（建议 ≤50000），逐段 push。
- 切片用
hugeArr.slice(i, i + chunkSize)，注意结束索引动态计算，避免越界或漏项 - 每次
arr.push(...chunk)或arr.push.apply(arr, chunk)都在安全范围内 - 若追求极致内存友好，可用 for 循环单次 push 一项，但性能下降明显，一般不必要
什么时候该换思路？
如果只是要合并结果、不要求复用原数组，arr1.concat(arr2) 是更优解：它不依赖参数传递，无栈溢出风险，且现代引擎对其做了大量优化。
-
concat返回新数组，适合非就地修改场景 - 对百万级数组，
concat的实际耗时远低于分块push，也比扩展运算符稳定 - 若必须就地修改，再考虑分块
push，而非硬扛
