JavaScript递归深度由引擎调用栈容量决定，Chrome约13500层、Firefox约4000–7000层、Safari约20000–25000层；受参数大小、严格模式、嵌套调用及开发者工具影响；推荐改用迭代、微任务或运行时降级保障安全。
JavaScript递归调用的深度限制主要由引擎的调用栈（call stack）容量决定，而非语言标准规定。不同浏览器使用的 JavaScript 引擎不同，导致实际可支持的最大递归深度存在明显差异，且同一引擎在不同硬件、内存配置或嵌套环境（如 Web Worker）下也会浮动。
主流浏览器的典型递归深度范围
实测中，在常规页面环境下（非严格模式、无大量闭包或大对象引用），各浏览器大致支持的同步递归最大深度如下：
- Chrome（V8 引擎）：约 12,000 ~ 18,000 层（取决于 Chrome 版本和系统内存；v110+ 常见值为 13,500 左右）
- Firefox（SpiderMonkey）：约 4,000 ~ 7,000 层（较保守，对栈空间控制更严格）
- Safari（JavaScriptCore）：约 20,000 ~ 25,000 层（通常最宽松，但 macOS/iOS 设备间略有差异）
- Edge（Chromium 内核）：与 Chrome 基本一致，因共用 V8
影响递归深度的关键因素
实际能走到多少层，不只看浏览器型号，还受以下条件直接影响：
- 函数参数与局部变量大小：每个调用帧占用栈空间，传入大数组、长字符串或闭包会显著压缩可用深度
- 是否启用严格模式：严格模式下部分优化可能略微改变栈帧结构，但影响微弱，不可依赖
- 嵌套调用链长度：若递归函数内又调用其他深层函数（如 Promise 回调、事件处理器），会提前耗尽栈空间
- 开发者工具是否开启：Chrome DevTools 打开时，部分版本会额外注入调试钩子，使栈深度减少 10%~20%
如何安全处理深层递归需求
当业务逻辑天然需要高深度（如解析深层嵌套 JSON、树形结构遍历），不应依赖浏览器默认栈容量。推荐替代方案：
立即学习“Java免费学习笔记（深入）”；
- 改写为迭代（Stack 模拟）：用数组手动维护待处理节点，避免调用栈增长。适用于 DFS 类场景
- 使用 async/await + setTimeout 或 queueMicrotask：将每次递归拆成微任务或宏任务，让栈在每轮后清空，实现“伪递归”
- 尾调用优化（TCO）注意：ES6 规范虽定义了尾调用优化，但目前仅 Safari 在严格模式下稳定支持；Chrome 和 Firefox 已明确不计划实现，不可用于生产环境保障
- 运行时检测并降级：用 try/catch 捕获 RangeError，回退到迭代或分片处理逻辑
快速验证当前环境递归极限的方法
可在控制台运行以下代码粗略探测（注意：可能触发页面卡顿）：
function measureMaxDepth(n = 1) {
try {
return measureMaxDepth(n + 1);
} catch (e) {
return n;
}
}
console.log('Max recursion depth:', measureMaxDepth());
该方法简单有效，但结果为近似值——真实安全上限建议预留 20% 余量，例如测得 15000，代码中应限制在 12000 层以内。
