大内存解压本身不会导致栈溢出，真正原因是同步递归或深度嵌套调用；需区分“Maximum call stack size exceeded”（栈溢出）与“heap out of memory”（堆溢出）；应改用迭代+显式栈、分块处理、深度守卫及Web Worker等方案。
大内存解压本身不会直接导致栈溢出，真正出问题的是解压过程中使用的同步递归算法或深度嵌套调用——比如用递归解析深层嵌套的 JSON、层层 unpack 嵌套压缩包、或在解压逻辑中误用递归遍历超深结构。栈溢出的关键诱因是调用栈帧持续堆积，而非数据体积大。
先确认是不是真栈溢出
看到“Maximum call stack size exceeded”或“RangeError: Maximum call stack size exceeded”才是栈溢出；若报“JavaScript heap out of memory”，则是堆溢出，需走内存快照+泄漏分析路径，和栈无关。
Chrome 中可快速验证：打开 DevTools → Console → 输入 console.log(new Array(1e6).fill(0)) 不会崩；但执行一个 2 万层递归函数就会立即报栈溢出。
解压场景中常见的栈溢出源头
- 用递归方式解析嵌套极深的压缩元数据（如 ZIP 中的目录树、TAR 的递归 header 链）
- JSON.parse() 后对结果做深度递归遍历/克隆/校验，且对象嵌套超过 1.5 万层
- 自实现的 LZ77/LZMA 解码器中，状态机用递归推进而非循环+栈模拟
- 在 Web Worker 中仍使用同步递归，误以为“换线程就安全”——其实每个线程调用栈限制独立且相近（Chrome 约 13000 层）
可靠解法：用迭代替代递归 + 显式控制深度
不依赖尾递归优化（V8 默认不启用），而是彻底消除调用栈增长：
- 把递归遍历改为显式栈（
Array模拟）+ while 循环，例如：
不用traverse(node) { if (node.children) node.children.forEach(traverse); }，
改用const stack = [root]; while (stack.length) { const n = stack.pop(); if (n.children) stack.push(...n.children); } - 对解压流程做分块：不一次性解完整包，而是按 chunk 读取、解压、处理、释放，用
Uint8Array.subarray()切片，避免构造中间大数组 - 加硬性递归深度守卫：在任何可能递归的函数入口加
if (depth > 1000) throw new Error('Recursion too deep');，并让调用方捕获后降级为迭代
配合异步调度，防主线程卡死
即使改成迭代，若单次解压操作耗时过长（如解 100MB LZ4），仍会阻塞 UI 和 GC。建议：
- 用
setTimeout(fn, 0)或queueMicrotask()把大任务切片，每处理 1~5ms 就让出控制权 - 在 Web Worker 中运行解压逻辑，主线程仅负责传递 ArrayBuffer 和接收进度
- 对超大文件，优先选用流式解压库（如 StreamSaver.js + SheetJS 的流式读取能力），避免全量加载到内存
栈溢出本质是控制流设计问题，不是数据量问题。只要去掉深层调用链，再大的解压任务也能稳住调用栈。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
