工程中落地递归需兼顾正确性、可维护性与鲁棒性：必须穷举所有终止路径，校验异常输入与递归深度，避免栈溢出和重复计算，优先采用记忆化、尾递归或迭代替代。
递归写得对，不等于用得稳。工程中真正落地的递归，必须兼顾正确性、可维护性与运行时鲁棒性。
明确递归基，且覆盖所有边界
递归基不是“大概有个出口”，而是必须穷举所有可能的终止路径。比如处理链表或树节点时，null / nullptr / NULL / 0 / -1 等不同语言的空值表示都要单独判断；输入为负数、超大数、非法字符等异常情况也应纳入基线检查，不能依赖调用方“传得对”。常见错误是只写 n == 0 却漏掉 n ，导致无限递归。
确保每次调用都严格缩小问题规模
递归体中传入的参数，必须使问题朝递归基单向收敛。例如阶乘中用 n-1 是安全的，但若误写为 n/2（整数除法下 n=1 时仍为 1）或 n-0，就会卡死。建议在递归调用前加断言或日志，验证参数是否变小，尤其在涉及浮点运算、字符串切片、指针偏移等场景中。
主动控制深度，防栈溢出
默认栈空间有限（通常几 MB），深度超过数千层极易崩溃。工程做法包括：
- 对输入规模做预检，如
if (n > 1000) return error - 增加显式深度参数，递归调用时传入
depth + 1，并在入口处校验if (depth > MAX_DEPTH) - 关键服务中改用迭代+显式栈（如用
std::stack或数组模拟），完全规避系统栈限制
避免指数级重复计算，优先考虑记忆化或重构
像斐波那契、组合数等天然存在重叠子问题的递归，未经优化不可直接上线。实用方案有：
- 加哈希表或数组缓存已算结果（memoization），首次计算后直接查表
- 改写为尾递归形式（如
f(n, acc)），配合编译器优化（TCO）减少栈帧 - 彻底转为自底向上迭代，空间换时间，逻辑更可控
记住：递归是表达方式，不是性能承诺。工程目标是“结果正确 + 响应可控 + 故障可溯”，不是“看起来像数学定义”。
