递归函数必须有明确终止条件，否则栈溢出导致崩溃；参数优先传值或const引用，禁用unique_ptr&；尾递归优化不可靠，高深度应改用显式栈。
递归函数必须有明确的终止条件
没有终止条件的递归会无限调用，最终触发栈溢出——程序直接崩溃，错误信息通常是 Segmentation fault (core dumped) 或在 Windows 上弹出“stack overflow”对话框。这不是内存不足，而是函数调用帧不断压栈，超出了系统默认栈空间（Linux 一般 8MB，Windows 约 1MB）。
实操建议：
- 写完递归函数第一件事：圈出所有
return分支，确认至少有一个不依赖递归调用 - 用小数据手动走一遍逻辑，比如计算
factorial(0)、factorial(1)，看是否真能退出 - 避免用浮点数或指针比较作为终止依据（精度误差、空指针未检查都可能跳过出口）
参数传递方式影响递归安全性和性能
传值（int n）最安全，但对大对象（如 std::vector、自定义类）会频繁拷贝，拖慢速度；传引用（const std::vector<int>& data</int>）快，但若递归中修改了原对象，后续调用可能拿到意外状态。
常见错误现象：递归处理树结构时，误用非 const 引用遍历子节点，导致父节点数据被子递归改乱。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 基础类型（
int、size_t）、小结构体（≤16 字节）优先传值 - 容器、字符串、大对象一律传
const&，除非你明确需要在某一层修改并让下层看到 - 绝对不要传
std::unique_ptr<t>&</t>进递归——移动语义会让上层指针变空，下层访问直接 UB
尾递归优化不是 C++ 标准保证的行为
即使你把递归写成尾调用形式（最后一步就是调自己），g++ 或 clang++ 在 -O2 下可能优化，但 MSVC 基本不优化，且标准完全不承诺。别指望靠它避免栈溢出。
使用场景：当递归深度可能上千（比如解析嵌套 JSON 或深层 DOM），又不想改迭代，就得自己拆栈或换算法。
实操建议：
- 用
__builtin_frame_address(0)（GCC/Clang）粗略估算当前栈深，超过阈值（如 500）就抛异常或切到迭代 - 真正高深度场景，直接用显式栈（
std::stack）模拟递归，控制内存分配位置 - 别信网上“加
[[gnu::always_inline]]就能尾优化”的说法——inline 和尾调用是两回事
调试递归时别只看最后一层崩溃
很多新手在 gdb 里看到 Segmentation fault 就停在最内层调用，其实问题往往出在中间某次参数算错（比如 n-1 写成 n+1），导致越界或负值，只是延迟几轮才爆。
实操建议：
- 加简单日志：
std::cout ，但注意重定向输出可能缓冲，加 <code> - 用
gdb的break function_name+condition $bpnum n 设置条件断点 - 对关键参数做断言：
assert(n >= 0 && "n must not be negative in factorial");
递归看着简洁，但每多一层，出问题的组合就翻倍。最麻烦的不是写不出来，是写出来跑几次没问题，一换输入就崩——这时候大概率是终止条件覆盖不全，或者参数传递时隐式转换闯了祸。
