JavaScript递归需从终止条件、参数收敛、深度防护三方面协同设防：终止条件须可达、全覆盖、无遮挡；须手动传入depth参数并设阈值守卫；不可预估深度时应转为迭代或显式栈。
JavaScript递归算法的边界检查不是“加个if就行”，而是要从终止条件、参数收敛、深度防护三方面协同设防。只靠单一手段容易漏掉逻辑死角，真正安全的递归必须层层兜底。
终止条件必须可达、全覆盖、无遮挡
很多溢出问题表面是深度大，实则是终止条件形同虚设。关键不在“有没有”，而在“能不能走到”：
-
可达性优先：每次递归调用后，参数必须向终止值靠近。比如
factorial(n - 1)配n === 0是安全的；若写成factorial(n + 1)却用n === 0判断，永远无法触发退出 -
全覆盖所有分支：二叉树遍历中，空节点、左子树、右子树三种路径都得有
if (!node) return，不能只放在某一分支里 - 无遮挡写在最前：终止判断必须放在函数开头，避免被前置计算、异常或提前return绕过。常见错误是先解构对象再判空，结果一解构就报错，根本走不到判断逻辑
手动加入递归深度守卫
即使终止条件完美，恶意输入或超深结构（如万层嵌套JSON、链表）仍可能压垮调用栈。这是必须加的第二道防线：
- 把
depth作为参数传入，初始调用设为0，每次递归+1 - 函数入口立即检查：
if (depth > 1000) throw new Error('Recursion too deep') - 阈值不是拍脑袋定的：Chrome 实测约13500层，但开启 DevTools 或传大对象会降到11000以下；业务场景建议设1000–2000，留足余量
- 别依赖全局计数器——易被并发或闭包污染，参数传递最干净
主动降级：递归转迭代或显式栈
当递归深度不可预估（如解析用户上传的嵌套配置、遍历动态DOM树），光靠守卫不够，得从根本上摆脱调用栈依赖：
立即学习“Java免费学习笔记（深入）”；
-
简单逻辑直接改循环：阶乘、斐波那契、数组扁平化等，用
for/while替代，零栈增长 -
复杂结构用显式栈模拟：把待处理节点/状态存进数组或
Stack，循环pop()处理，遇到子任务就push()新状态。例如DFS遍历树，不再调用自身，而是管理一个待访问节点队列 -
尾递归写法是好习惯，但别指望引擎优化：V8等主流引擎默认不启用TCO，写成
factorial(n - 1, acc * n)能提升可读性，也便于后续用trampoline等工具转换，但不能当作防溢出方案
特别注意循环引用和参数膨胀
这两类问题常被忽略，却直接挤占单层栈空间：
- 深层相等比较、克隆等场景遇循环引用（
a.b = a），必须用WeakMap记录已访问对象对，避免无限递归 - 别把大对象按值传入递归函数——每次调用都在栈上复制一份。改用指针传递（即直接传引用），必要时用
const保证只读 - 处理数组/字符串时，传
start/end索引，而非切片生成新副本，减少局部变量内存占用
