递归方法抛 StackOverflowError 是因调用深度超过 JVM 栈容量限制，本质是栈帧持续压入致栈溢出；常见于 base case 缺失、未收敛或浮点数精度误差等场景，Java 不支持尾递归优化，安全做法是转为迭代并手动维护状态栈。
递归方法为什么突然抛 StackOverflowError
Java 递归调用本质是不断压栈，每次调用都新增一个栈帧。当深度超过 JVM 默认栈大小（通常 1MB 左右，对应约 1000–8000 层，取决于局部变量数量），就会触发 StackOverflowError。这不是代码写错了，而是资源耗尽了。
- 常见错误现象：
Exception in thread "main" java.lang.StackOverflowError，堆栈里全是同一方法的重复调用痕迹 - 不是所有递归都危险：计算
factorial(10)安全，但factorial(10000)极大概率崩 - JVM 可调栈大小（
-Xss512k），但治标不治本——栈再大也有限，逻辑没兜底就迟早出事 - 尾递归在 Java 中**不被 JVM 优化**，写成尾递归形式也没用，照样压栈
base case 写错的三种典型表现
基线条件（base case）是递归退出的唯一阀门。写错它，递归就停不下来，直到栈溢出。
- 漏写或条件恒为 false：比如
if (n == 0) return 1;却忘了处理n < 0，输入负数直接死循环压栈 - 递推步没向
base case靠拢：比如本该n - 1却写了n + 1，越调越大 - 浮点数或对象引用做递归变量：用
double当参数递归极易因精度问题错过base case；用未重写equals()的对象判断相等，也可能永远进不了终止分支
如何安全地把递归转成迭代（以树遍历为例）
当递归深度不可控（如解析深层嵌套 JSON、遍历未知深度的树结构），必须换迭代。核心是手动模拟调用栈，用 Deque 或 Stack 存状态。
- 不要硬记“前中后序”，先想清楚：每次迭代要保存什么？——通常是当前节点 + 下一步要做的动作（比如“访问左子”还是“访问右子”）
- 用
ArrayDeque比Stack更高效（后者是同步类，且继承自过时的Vector） - 示例（简化版前序迭代）：
Deque<TreeNode> stack = new ArrayDeque<>(); stack.push(root); while (!stack.isEmpty()) { TreeNode node = stack.pop(); if (node != null) { visit(node); // 处理当前 stack.push(node.right); // 注意：先 push right，再 push left，保证 left 先 pop stack.push(node.left); } } - 性能影响：迭代避免了方法调用开销和栈帧分配，内存占用更可控；但代码可读性略降，调试需多看栈内容
哪些场景其实不该用递归
递归是优雅的抽象，但不是银弹。有些问题天然不适合，强行用反而埋雷。
立即学习“Java免费学习笔记（深入）”；
- 线性数据遍历（数组、List）：用
for或增强for直观又零开销，递归纯属增加栈压力 - IO 或网络调用嵌套：比如回调地狱式递归请求，失败重试逻辑混在递归里，异常传播难追踪，超时控制也变复杂
- 需要精确控制执行顺序或中断的场景：递归中途想 break？只能靠异常或额外标志位，不如迭代中直接
break干脆 - Android 或嵌入式环境：栈空间更紧张，
StackOverflowError可能直接导致进程崩溃，比服务端更敏感
递归本身不难，难的是预判它的边界。很多人卡在“能跑通”，却没想清“在什么输入下会崩”。栈溢出不是偶发 bug，是设计信号——说明你还没真正定义好问题的停止条件，或者没评估好数据规模与运行环境的匹配度。
