spread展开大数组本身不直接导致栈溢出，但若在递归、深层遍历或超长参数传递中使用，会因隐式循环和调用链堆叠引发栈溢出；应改用循环或reduce等替代方案。
大数组用 spread 展开（[...arr]）本身不会直接导致栈溢出，但它可能成为栈溢出的“导火索”——尤其在递归、嵌套调用或深层对象遍历场景中。真正危险的是 spread 触发的隐式循环 + 递归调用链，而非展开动作本身。
看是否在递归路径中使用 spread
spread 在每次展开时会逐项读取数组元素，如果该操作出现在递归函数内部，且数组长度较大，就会快速堆叠栈帧。
- 例如：对一个含 10 万项的数组做递归扁平化，并在每层都写
[...item]，实际等效于深度为 10 万的递归调用 - 再如：
function deepCopy(obj) { return Array.isArray(obj) ? [...obj].map(deepCopy) : { ...obj } }—— 遇到循环引用或深层嵌套数组时极易爆栈 - 关键信号：错误堆栈里反复出现同一函数名，且调用深度超过 500–1000 层（Chrome 约 16k 帧上限，Node.js 默认约 12k）
检查 spread 是否用于超长参数列表传递
spread 常用于函数调用传参，如 Math.max(...hugeArray)。虽然这不是递归，但 V8 引擎会对超长参数列表做内部展开处理，极端情况下也可能触发栈相关限制（尤其配合自定义构造器或 Proxy 陷阱时）。
- 数组长度 > 10⁵ 时，
Math.max(...arr)在部分 Node.js 版本会报RangeError: Maximum call stack size exceeded - 替代方案：改用循环或
reduce，例如arr.reduce((a, b) => Math.max(a, b)) - 注意：不是所有引擎行为一致；Safari（JavaScriptCore）对此容忍度略高，Chrome/V8 更敏感
留意与结构赋值、解构、rest 参数的组合使用
spread 经常和解构一起出现，而解构在遇到深层嵌套对象/数组时，会隐式触发多层属性访问和临时变量分配，间接增加单次调用的栈帧体积。
- 比如：
const [a, b, ...rest] = veryDeepArray;中rest若指向一个仍需进一步展开的子结构，就可能嵌套触发更多 spread - 再如：
const { items: [...flattened] } = data;—— 解构 + spread + 深层属性访问，三者叠加放大风险 - 调试建议：在报错前加
console.log(arr.length)和console.trace()，确认是否在某次展开后立即崩溃
用 Chrome DevTools 快速验证
运行疑似代码时打开 Performance 面板录制，或直接在 Console 执行 console.trace() 查看当前调用深度；也可用以下小技巧预判：
- 在浏览器控制台输入
console.log(new Error().stack.split('\n').length)看当前基础栈深 - 对目标数组执行
[...arr.slice(0, 10000)].length测试阈值，逐步加量观察何时开始报错 - 若用 Babel 或 TypeScript 编译，注意其对 spread 的降级转换（如转成
Array.from+for循环），可能掩盖真实栈行为
