设计递归终止条件需三重保障：一是覆盖所有边界（如n≤0、node==null、list为空），二是确保参数严格收敛（如n-1而非abs(n-1)），三是加深度守卫（如depth>500抛异常）；优先用迭代替代深度不确定的递归。
设计正确的终止条件是防止栈溢出的第一步，但光写一个 if (n == 0) return; 远远不够——它必须能真正拦截所有可能的执行路径，并确保每次递归都在向这个条件靠近。
覆盖所有输入边界，不漏掉任何“意外”
终止条件要主动兜住异常输入，而不是依赖“用户不会传负数”这类假设：
- 数值类：用
if (n 替代 <code>if (n == 1)，避免n = -5直接跳过出口继续调用 - 引用类（树、链表）：入口第一行就写
if (node == null) return;，且必须在访问node.left或node.next之前 - 集合类：先判
list == null || list.isEmpty()，别只靠size() == 0，否则空指针会提前中断流程，让终止逻辑失效
确保参数每次调用都严格收敛
即使有终止判断，如果参数不往出口走，条件永远不触发：
- 阶乘递归中传
n - 1是安全的；传Math.abs(n - 1)则可能让n = -1 → 0 → 1 → 0 → …循环 - 遍历链表时，
process(node.next)前必须确认node != null && node.next != null，否则null.next会抛空指针，不是栈溢出，但逻辑已断 - 数组索引递归，用
if (i >= arr.length)比if (i == arr.length)更鲁棒，防止越界跳过判断
加深度守卫，给不确定性兜底
再严谨的终止逻辑，也扛不住恶意嵌套或数据异常。必须设第二道防线：
- 方法签名加
int depth参数，入口立即检查：if (depth > 500) throw new IllegalArgumentException("Recursion too deep"); - 普通业务设上限 500；已知结构（如B+树、配置模板）深度可控的，设 80–200 更稳妥
- 别用
-Xss扩栈代替守卫——这只会掩盖问题，还降低并发能力
能迭代就不递归，尤其深度不确定时
对用户输入、外部JSON、自定义嵌套结构等场景，终止条件再全也不如不用递归：
- 用
Deque<node></node>在堆内存模拟调用栈，把“压栈”从线程栈移到可伸缩的堆空间 - 循环中每次处理一个节点，子任务不调自身，而是入队/入栈，彻底规避栈帧堆积
- 二叉树中序遍历、表达式解析、模板渲染等，都有成熟迭代实现，万层嵌套也不怕
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
