关键在于确保每条执行路径都抵达明确停止点，终止条件须严密前置且覆盖所有输入边界；空值、负数、集合边界易绕过判断；应加深度参数限界；高风险场景宜改用迭代；增大-xss非根本解法。
关键不是“加个 if”，而是让每条执行路径都必然抵达一个明确、可覆盖所有输入的停止点。终止条件必须严密、前置、无遗漏，否则 JVM 会持续压栈直到崩溃。
覆盖所有输入边界和异常路径
很多 StackOverflowError 并非因为递归太深，而是终止判断被绕过。重点检查：
-
空值与 null 引用：比如遍历树节点前没判
node == null，调用process(node.left)就可能触发空指针后继续递归 -
负数或越界值：阶乘写
if (n == 1)，但输入是 0 或 -5 就跳过判断，直接进入factorial(n-1) -
集合类边界：处理列表时只判
list.size() > 0，却忽略list.isEmpty()在空集合下是否被正确捕获
用整型深度参数主动设限
即使逻辑上出口存在，恶意输入（如环形引用、超深嵌套）仍可能突破预期。加一层显式防护更可靠：
- 方法签名增加
int depth参数，首次调用传 0，每次递归传depth + 1 - 入口处立即校验：
if (depth > 500) throw new IllegalStateException("Recursion too deep"); - 阈值按场景调整：普通业务建议 ≤ 500；已知树高上限为 100 层的，设 200 更安全
高风险场景直接改用迭代
当递归深度不可预估（如解析用户上传的嵌套 JSON、遍历任意层级配置文件），迭代才是根本解法——它把栈从线程内存移到堆内存，彻底脱离 -Xss 限制：
- 用
Deque<context></context>存待处理状态（节点、索引、上下文对象） - 循环
pop()处理当前项，遇到子任务就push()新状态，不再 self-call - 例如：千层二叉树递归遍历必崩，而基于
Deque的中序迭代版本可稳定运行，且内存更可控
慎用 -Xss 调栈大小
增大栈空间只是临时排查手段，不是修复方案：
-
-Xss2m不解决逻辑缺陷，只推迟崩溃时间 - 单线程栈扩大，会挤占其他线程内存，在多线程服务中易引发连锁问题
- 无法突破操作系统硬限制（如 Windows 默认 1MB），JIT 编译状态变化还可能导致效果不稳定
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
