c语言递归必然栈溢出：每次调用均压入新栈帧，栈空间固定（windows约1mb、linux约8mb），超限即崩溃；尾递归优化不可靠，真正防御需迭代替代或显式堆管理。
会，而且几乎必然——只要递归深度超过栈容量，就不是“可能”，而是“一定”崩溃。
每次递归调用都在栈上压一个新栈帧
函数调用不是免费的。每次进入 recursive_func()，系统就在当前线程栈上分配一块内存（栈帧），存返回地址、参数、局部变量、寄存器备份等。这个过程不涉及堆，不触发 new/malloc，纯靠栈指针向下移动。栈空间是操作系统在创建线程时就划死的（Windows 默认约 1MB，Linux 一般 8MB），不能动态扩容。
- 栈帧大小取决于函数参数数量、局部变量体积（比如
int buf[1024]直接吃掉 4KB）、编译器对齐策略和是否启用优化 - 递归越深，栈帧越“叠高”，直到栈顶撞上保留区边界，OS 立即终止进程（Linux/macOS 发送
SIGSEGV，Windows 弹EXCEPTION_STACK_OVERFLOW） -
std::stack_overflow不是 C++ 标准异常，try/catch完全捕获不到；它属于底层信号/结构化异常，常规异常处理机制在这里失效
为什么 tail recursion 优化不可靠
只有严格满足尾递归定义的函数（递归调用是函数体最后一条语句，且其返回值直接作为本函数返回值），GCC/Clang 在 -O2 以上才可能将其转为跳转（jump），复用当前栈帧。但以下情况会禁用该优化：
- 函数内有析构函数（如局部
std::string、std::vector）需要在返回前执行 - 存在异常处理（
try/catch块） - 调用虚函数或使用
dynamic_cast - 递归调用不是纯尾调用，例如
return f(n-1) + f(n-2)或return process(f(n-1))
也就是说，你写的所谓“尾递归”，编译器大概率没优化；而你依赖它不爆栈，结果就是上线后某次输入稍大就静默崩溃。
怎么快速确认就是递归栈溢出
别猜，看回溯链：
- 用
gdb ./a.out运行崩溃程序，执行bt—— 如果输出几百上千行几乎全是同一函数名（如#12345 recursive_step() at algo.cpp:42），基本锁死 - 崩溃点高度可复现：输入规模从 9999 到 10000 就崩，且崩的位置总在固定深度附近
- 把递归改成
std::stack迭代版本后问题消失，就是铁证 - 加一个简单计数器：
if (depth > 1000) { std::abort(); }，运行后立即 abort，说明还没到栈极限，是逻辑问题；如果加了反而不崩了，那原来就是栈真满了
真正有效的防御不是“调大栈”，而是绕开栈
修改链接器栈大小（如 MSVC 的 /STACK:8388608 或 GCC 的 -Wl,--stack=8388608）只是拖延问题——它让崩溃阈值从 5000 层变成 40000 层，但依然存在。更危险的是，它掩盖了设计缺陷，让问题在更大规模数据、更受限环境（如嵌入式、容器内存限制）下突然爆发。
- 对树/图遍历、路径搜索等天然深度不确定的场景，必须用
std::stack或std::queue显式管理状态，把“待处理节点”放在堆上 - 对算法类递归（如快排分区、归并拆分），改写为 while 循环 + 辅助栈/队列，控制迭代深度
- 若必须保留递归接口（如暴露给用户的 API），内部仍应设硬性深度上限（如
if (depth > 1000) throw std::runtime_error("recursion limit exceeded")），而不是任其滑向崩溃
栈空间是线程级的、静态分配的、不可增长的资源。把它当“临时缓存”用可以，但绝不能当作“无限容器”来依赖——这是所有深递归崩溃背后最常被忽略的底层事实。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
