递归必须有明确终止条件，否则会导致StackOverflowError；需在每次调用前判断基础情形（如n==0或node==null），且该条件须为纯逻辑判断、逐步逼近。
递归方法必须有明确的终止条件
没有终止条件的递归会直接导致 StackOverflowError，这是 Java 中最典型的递归崩溃现象。JVM 每次调用方法都在栈上压入一个帧，无限递归会让栈空间耗尽。
- 检查每次递归调用前是否判断了基础情形（base case），比如
n == 0或node == null - 终止条件不能依赖外部变量或副作用——它得是纯逻辑判断，且每次递归后必须更接近该条件
- 常见错误：把
if (n 写成 <code>if (n == 1)，漏掉n == 0导致负数输入时无限递归
避免在递归中反复创建对象或拷贝大结构
Java 是值传递，但对象引用仍可能引发隐式开销。递归深度大时，每层都新建 ArrayList 或字符串拼接，会快速吃光堆内存，甚至触发频繁 GC。
- 优先复用参数传入的可变容器，比如用
List<integer> result</integer>作为递归参数，而不是每层return new ArrayList(...) - 字符串拼接别用
+，改用StringBuilder并作为参数传递下去 - 树遍历中不要每次递归都
new TreeNode(...)，除非真需要副本
递归深度超过 1000 层就该考虑迭代替代
默认 JVM 栈大小约 1MB，粗略估算每层占 1–2KB，意味着安全递归深度通常在 500–1000 层之间。实际项目中一旦涉及用户输入控制深度（如解析嵌套 JSON、计算超大斐波那契数），必须设防。
- 加一层深度计数参数，比如
dfs(node, depth, maxDepth)，到达maxDepth时抛出IllegalArgumentException或回退到迭代 - 用显式栈（
Deque）重写递归逻辑，尤其适合 DFS 类场景；Stack已过时，优先用ArrayDeque - 注意：尾递归在 Java 中不被 JVM 优化，写成尾递归形式也没用，别为了“看起来优雅”牺牲可读性和安全性
调试递归时优先打日志而非断点单步
在 IDE 里对深层递归逐层 F8，很容易迷失在哪一层、参数是什么值。而且断点本身会拖慢执行，让栈溢出更难复现。
立即学习“Java免费学习笔记（深入）”；
- 加轻量级日志：在进入和返回处打印
depth和关键参数，例如System.out.printf("fib(%d)@%d\n", n, depth) - 用
Thread.currentThread().getStackTrace()获取当前调用深度（仅调试，勿上线） - 如果必须断点，设在 base case 处，配合「条件断点」（如
depth > 10）过滤掉浅层干扰
return f(n-1) + f(n-2)，而是想清楚哪一层该停、哪些状态必须传下去、以及谁来为栈空间负责。 
