关键在于每条执行路径都必须抵达明确、不可绕过的终止点；递归入口需立即检查基础情形，守卫阈值普通业务≤500、深度≤100时设200，作为暴露问题的双保险。
关键不是“加个 if”，而是让每条执行路径都必然抵达一个明确、可达、不可绕过的终止点。
确保每个递归入口都有对应的基础情形判断
递归方法一进入就要检查是否该停。不能只在某一分支里写出口，也不能把判断放在递归调用之后。
- 正确做法：每次调用前先判
if (n ，满足即返回，不往下走 - 错误常见：先操作再判断，或只对正数判断
if (n == 1)，却忽略n = 0或负数输入，导致跳过出口继续调用 - 特别注意空集合、空节点、null 参数——这些是最容易被漏掉的边界情况
验证参数变化方向是否收敛到基础情形
递归调用传入的新参数，必须让问题规模严格变小，并最终触达基础情形。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 比如处理链表，
process(node.next)前必须已确认node != null && node.next != null - 处理数组索引时，
i + 1要配if (i >= arr.length)；用i - 1就得配if (i - 若参数可能不减反增（如误写
factorial(n + 1)），基础情形永远无法到达
覆盖所有逻辑分支，杜绝隐式递归路径
多个 if-else、switch 或嵌套条件中，任何一条分支都不能遗漏出口检查。
立即学习“Java免费学习笔记（深入）”；
- 例如树遍历中，左子树递归前判
node.left != null，右子树同理，不能只判一次父节点 - 状态机类递归（如解析表达式）需为每个可能的状态转移定义退出条件，而非仅依赖顶层输入
- 避免在异常处理块、finally 或回调中无意触发二次递归
配合深度守卫，给不确定性兜底
即使基础情形逻辑正确，异常输入（如超深嵌套 JSON、恶意构造的树）仍可能突破预期深度。
- 为方法增加
int depth参数，入口处立即校验：if (depth > 500) throw new StackOverflowPreventException() - 阈值按场景设：普通业务建议 ≤ 500；已知结构深度 ≤ 100 的，设 200 更稳妥
- 这个守卫不替代基础情形，而是双保险——它不修复逻辑缺陷，但能快速失败、暴露问题
