基准条件是递归函数安全返回的唯一出口，必须覆盖所有输入终点且参数须单调趋近；如阶乘中n==0或n==1因数学定义和不可分性成为正确基准，错写将导致失控递归。
基准条件就是递归函数的“刹车踏板”
没有基准条件的递归，就像踩着油门不松脚的车——每次调用都生成新栈帧，直到栈空间耗尽，抛出 stack overflow 错误或直接崩溃。基准条件不是可选逻辑，而是函数能安全返回的唯一出口。
为什么 n == 0 或 n == 1 常被用作阶乘的基准条件
因为数学定义上 0! = 1、1! = 1，它既是终止依据，又天然满足“问题规模不可再分”的要求。若错写成 n == 2，当输入 n = 1 时会跳过该分支，继续调用 factorial(0)、factorial(-1)……最终失控。
- 基准条件必须覆盖所有可能的输入终点，不能只覆盖“常见值”
- 它必须在参数未进一步恶化前触发，比如对负数输入，应提前拦截，而不是等递归到
-100才失败 - 若函数接受多种类型（如指针、接口、结构体），基准条件得检查
nil或空值，而非仅数值边界
递归调用中参数没变小，基准条件就形同虚设
即使写了 if n ，但递归分支仍是 <code>return n * factorial(n)（漏了 -1），那这个 if 永远不会被执行。常见错误包括：
- 递归调用传入原值（如
factorial(n)而非factorial(n-1)） - 状态更新在判断之后，导致每次进入函数时参数和上次完全一样
- 浮点数递归中用
==判断终止（如x == 0.0），因精度丢失永远不成立 - 处理树结构时，误将子节点数量作为收敛依据，而实际子节点为空却未进入基准分支
加深度限制是兜底，不是替代基准条件
有些语言（如 PHP）建议用深度计数器防崩，但这只是防御性补丁。例如传入非法数据导致根本进不了基准逻辑，靠深度限制顶多让程序“慢一点挂”，而非正确退出。
- 深度参数应作为额外校验，比如
func traverse(node *Node, depth int) { if depth > 50 { return } ... } - 它不能代替语义正确的基准条件，否则业务逻辑仍会出错（比如本该返回具体值，却因超深直接返回空）
- Go 和 Java 等栈空间相对固定的环境，过度依赖深度限制反而掩盖真实逻辑缺陷
基准条件是否真正生效，不取决于你写了几行 if，而取决于：每次递归调用后，参数是否确定地、单调地向那个 if 分支靠近——少一步推演，就多一分死循环风险。
