递归函数必须有明确终止条件，否则无限调用导致栈溢出（Segmentation fault）；C++无运行时深度检查和默认尾递归优化，需手动确保每次递归参数趋近终止值并覆盖所有边界情况。
递归函数必须有明确的终止条件
没有终止条件的递归会无限调用，最终导致栈溢出（Segmentation fault 或 stack overflow）。C++ 不做递归深度检查，全靠程序员保证。
常见错误是把终止条件写错，比如用 n == 1 但输入可能是 0 或负数；或条件判断顺序颠倒，导致递归分支永远进不去终止分支。
- 始终先检查终止条件，再进行递归调用
- 对输入做边界校验（如
n < 0时直接返回或抛异常） - 用小数值手动走一遍逻辑（如
factorial(3)），确认调用链能自然收口
递归调用要缩小问题规模
每次递归必须让参数更接近终止条件，否则就是死循环。这不是语法要求，而是逻辑本质——比如计算阶乘，factorial(n) 要调用 factorial(n-1)，而不是 factorial(n) 或 factorial(n+1)。
容易被忽略的是“缩小”的方向是否一致：比如在二分查找递归中，若左右边界更新写反（left = mid + 1 写成 right = mid + 1），问题规模不缩反扩，也会卡住。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 确认递归调用的参数值比当前更“简单”或“更小”
- 数组类递归常用
arr + 1或下标start + 1缩小范围 - 树结构递归中，子节点一定比父节点离根更远、离叶子更近
注意栈空间和尾递归优化限制
C++ 标准不强制支持尾递归优化（TCO），即使写成尾递归形式（如把累加值作为参数传入），g++ -O2 可能优化，但 clang 或 MSVC 行为不一，不能依赖。
深递归（如 >10⁴ 层）在默认栈大小（Linux 通常 8MB，Windows 约 1MB）下极易崩溃，尤其在嵌入式或服务端长期运行场景。
- 避免无节制递归；深度不确定时改用显式栈（
std::stack）模拟 - 调试时可用
ulimit -s（Linux）临时调大栈，但上线前必须消除隐患 - 尾递归写法可读性未必更好，别为了“函数式风格”牺牲可维护性
传值 vs 传引用影响递归行为
递归中若需修改状态并透传给下层，传引用（int&）比传值更高效且语义清晰；但若误将局部变量地址传入，或在递归中反复取同一引用的地址，会导致未定义行为。
典型陷阱：在循环内递归调用时，用 for (int i = 0; i < n; ++i) dfs(arr[i], i)，但 arr 是临时容器或生命周期短的对象，下层访问时已析构。
- 只对确实需要共享/修改的状态用引用；纯计算型递归优先传值
- 避免在递归中返回局部变量的引用或指针
- STL 容器（如
std::vector）传值开销大，深层递归建议传 const 引用
递归不是语法糖，它是把问题拆解能力映射到调用栈上的过程。真正难的从来不是写个 return n * factorial(n-1)，而是想清楚“当前这层到底该做什么、交给下一层什么、拿到结果后怎么组装”。栈帧看不见，但每层的输入输出必须清清楚楚。
