栈溢出本质是调用栈“入栈速度远大于出栈速度”导致栈空间占满；V8等引擎设有限深度（约1~10万层），受单帧内存占用、递归终止条件、是否启用TCO等因素影响，超限即抛RangeError。

JavaScript 通过执行上下文栈（Call Stack）的深度限制，直接决定了函数能嵌套调用多少层。这个限制不是由语言规范明确定义的，而是由运行时引擎（如 V8）根据内存和安全策略设定的硬性边界。一旦嵌套过深，就会触发 RangeError: Maximum call stack size exceeded 错误。

执行上下文栈深度的本质

每次函数调用，JS 引擎都会创建一个新的函数执行上下文，并把它压入调用栈顶部。这个上下文包含该次调用的参数、局部变量、词法环境、this 绑定等信息。栈空间是有限的——每个栈帧（Stack Frame）占用一定内存，总深度受线程栈容量约束。

• V8 默认栈大小约为 1MB（具体值因平台、版本、内存压力而异）
• 每个简单函数调用的栈帧通常占几百字节；若含大量局部变量或闭包，会显著增大单帧体积
• 深度 ≠ 行数，而取决于“活跃的未返回函数数量”，即当前仍在栈中未出栈的上下文个数

如何估算或观察当前最大嵌套层级

你可以用递归函数主动试探边界，但更实用的是理解影响深度的关键因素：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 递归终止条件是否可靠：缺少 base case 或逻辑错误会导致无限压栈
• 函数体开销大小：定义大量 let/const 变量、大对象、嵌套块作用域，会增加单帧内存占用，从而降低可容纳层数
• 是否使用尾调用优化（TCO）：ES6 规范支持尾调用优化，但主流浏览器（包括 Chrome）至今未启用。因此普通递归无法规避深度增长
• 调试工具可实时查看：在 Chrome DevTools 的 Sources 面板中断点暂停后，右侧 Call Stack 面板会清晰列出所有栈帧，直观反映当前深度

为什么不能无限制增加栈深度

根本原因在于系统级约束：

立即学习“Java免费学习笔记（深入）”；

• JavaScript 运行在宿主进程（如浏览器渲染进程）中，共享其主线程栈空间
• 过深调用不仅耗尽栈内存，还可能阻塞事件循环，导致页面无响应
• 引擎主动设限，既是内存保护，也是防止恶意代码引发崩溃（如无限递归攻击）

实际开发中的应对策略

遇到栈溢出，不建议强行调高限制（不可控且不跨平台），而应重构逻辑：

• 将深度递归改为迭代（如用 while 循环 + 显式栈数组模拟）
• 对树/图遍历等场景，改用 BFS 或带状态的迭代器，避免隐式调用栈累积
• 必要时拆分任务，配合 setTimeout 或 queueMicrotask 让出主线程，重置调用栈
• 利用尾递归风格写法（虽暂不被优化，但语义清晰，便于未来迁移）