栈溢出主因是递归终止条件失效，排查需确保“看得见、停得住、可验证”：检查终止逻辑是否真实触发、参数是否向终态收敛、避免隐式递归与循环引用，并加深度限制或改用迭代。
遇到栈溢出（RangeError: Maximum call stack size exceeded）时，大概率是递归函数没写好终止条件——要么漏写、写错、逻辑绕过，要么终止判断依赖了不稳定的状态（比如异步结果未就绪就进入递归）。排查核心思路是：**让递归“看得见、停得住、可验证”**。
检查终止条件是否真实生效
别只看代码里有没有 if (baseCase) return，要确认它在运行时真能被命中：
- 打印或断点调试递归参数，观察每次调用时关键变量（如索引、计数器、状态标志）的实际值，确认它们确实在向终止方向变化
- 检查终止条件是否用了错误的比较符（比如该用
<=却写了<），或类型不匹配（如字符串"0"和数字0比较） - 若终止依赖外部状态（如
if (data.loaded)），确认该状态在递归前已被正确设置，而不是靠“等下一次异步回调”来满足
避免隐式递归和意外循环调用
有些递归不是直接调用自己，而是通过事件、回调、Promise 链间接触发：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 检查是否在事件监听器中反复添加自身（如
element.addEventListener('click', handler); handler = () => { ... handler(); }） - 异步递归常见陷阱：用
setTimeout(fn, 0)或Promise.resolve().then(fn)模拟延迟，但忘了加终止控制，导致无限调度 - 对象/数组深度遍历中，若结构存在循环引用（a 引用 b，b 又引用 a），未做已访问标记就会无限深入
加防护机制，让问题提前暴露
在开发阶段主动设限，比等崩溃更高效：
立即学习“Java免费学习笔记（深入）”；
- 给递归函数加深度计数参数：
function traverse(node, depth = 0) { if (depth > 100) throw new Error('Recursion too deep at ' + depth); ... } - 使用浏览器 DevTools 的“调用栈”面板，直接看到溢出前最后几十层调用，快速定位重复出现的函数名和参数模式
- 把递归改造成显式栈（while 循环 + 数组模拟调用栈），天然规避栈溢出，也更容易插入日志和断点
用尾调用优化（TCO）？现实很骨感
ES6 规范支持尾调用优化，但目前仅 Safari 完全实现，Chrome 和 Firefox 均未启用。所以不要依赖 return fn(...) 自动解栈。真正可靠的方案是：
- 重构为迭代（推荐：清晰、可控、无栈风险）
- 必要时用
queueMicrotask或setTimeout切割执行流（注意仍是异步，需重设计逻辑） - 对超深结构（如大型 AST、嵌套 JSON），考虑分片处理或流式解析
