最直接的办法是补全所有基准出口，确保每条路径都有明确终止条件；优先改用迭代替代深度不可控递归；慎用-Xss调大栈空间。
最直接的办法是补上明确的终止条件，让递归在某一层级必然停止。这不是“加个if就行”的表面操作，而是要覆盖所有可能路径，尤其警惕边界值和空状态被跳过的情况。
检查并补全所有基准出口
很多 StackOverflowError 不是因为递归太深，而是根本没出口。重点看三处：
- 每个递归调用前，是否都有对应的 if (base case) 分支？比如
n == 0、n 、<code>node == null、list.isEmpty() - 终止判断逻辑是否严密？例如写
if (n == 1)，但输入可能是负数或零，就会绕过判断继续调用 - 递归参数变化后是否仍安全？比如调用
process(node.left)前，必须先判node != null && node.left != null，否则空指针之后还可能触发下一层无效递归
主动限制递归深度
即使有出口，恶意或异常输入（如超深嵌套结构）也可能让递归远超预期。加一层深度守卫更稳妥：
- 为递归方法增加 depth 参数，每次调用传入
depth + 1 - 开头立即校验：
if (depth > 500) throw new RuntimeException("Recursion too deep: " + depth); - 阈值按场景设：普通业务建议 ≤ 500；树结构已知不超过 100 层的，设 200 更保险
优先改用迭代实现
对深度不可控的场景（如解析用户自定义嵌套 JSON、遍历任意层级配置），迭代才是治本之法——它把“压栈”从线程栈搬到堆内存，不再受 -Xss 限制：
- 用 Deque 或 Stack 存待处理状态（节点、索引、上下文对象）
- 循环 pop 处理，遇到子任务就 push 新状态，完全避免 self-call
- 例如二叉树中序遍历，递归版千层就爆栈，显式栈版本可稳定处理万层
慎用 -Xss 调大栈空间
这只是临时排查手段，不是解决方案。它不修复逻辑缺陷，反而可能掩盖问题：
- Java 启动加
-Xss2m可将单线程栈提至 2MB（默认约 1MB） - 多线程服务慎用：栈变大会挤占可用线程数，易引发
OutOfMemoryError: unable to create new native thread - 无法突破系统硬限（如 Windows 默认 1MB），且增大后仍可能被更深递归击穿
