Stack Overflow 主因是调用深度失控而非内存不足；Windows 默认栈1MB、Linux 通常8MB，深层递归或值传参大对象易致栈溢出，gdb 查调用栈重复模式可快速定位递归失控。
为什么 stack overflow 通常不是内存不足，而是调用深度失控
Windows 默认线程栈大小是 1MB，Linux 一般是 8MB（可通过 ulimit -s 查），但真正压垮栈的往往不是单次大数组，而是深层递归或过深的函数调用链。比如一个没设终止条件的 fibonacci 递归，n=50 就可能触发 stack overflow；又或者在递归中无意拷贝了大对象（如 std::vector 值传参），每层都压入副本，栈空间指数级增长。
关键判断点：gdb 中若看到大量重复的 main → func → func → func… 调用栈，基本可锁定为递归失控；若 crash 前只有一两层调用，更可能是局部大数组（如 int arr[1024*1024]）直接越界。
如何快速定位是递归过深还是局部变量过大
用编译器加调试信息 + 栈回溯是最直接方式：
- Clang/GCC 编译时加
-g -O0，运行崩溃后用gdb ./a.out→r→bt看调用栈深度和帧大小 - Windows 下用
Visual Studio启动调试，崩溃时打开「调用堆栈」窗口，观察是否出现明显重复模式 - 检查所有递归函数：是否有明确、可到达的 base case？是否所有分支都最终走向 base case？尤其注意条件判断里用了
==却该用的典型错误 - 搜索函数体内是否定义了超大栈变量，例如
char buf[65536]或未限制尺寸的std::array—— 这类应改用std::vector或堆分配
递归转迭代的三个实用策略（附最小改动示例）
不是所有递归都适合手动转迭代，但以下三类最常见、收益最大：
立即学习“C++免费学习笔记（深入）”；
-
尾递归：编译器（GCC/Clang 加
-O2）常自动优化为循环，但显式改写更可控。例如：// 原递归
int factorial(int n) { return n <= 1 ? 1 : n * factorial(n-1); }
// 改为迭代
int factorial(int n) { int r = 1; while (n > 1) { r *= n--; } return r; } -
树形遍历类递归：用
std::stack模拟调用栈，把“当前节点+状态”打包进结构体。避免递归时隐式保存的返回地址和寄存器上下文开销。 -
记忆化递归（Memoization）：如果原递归存在大量重复子问题（如
fib(n)反复算fib(3)），加std::unordered_map缓存结果，能同时降深度和降时间——有时缓存后递归深度自然就掉到安全范围。
栈空间不够时，哪些操作真有用，哪些只是错觉
调整栈大小是最后手段，且效果有限、移植性差：
- Linux 下
ulimit -s 16384（单位 KB）可临时扩栈，但上线环境通常禁止修改；进程启动前设置才生效，运行中无效 - Windows 下
editbin /stack:8388608 a.exe可改 PE 头栈预留值，但仅影响主线程，新线程仍用默认值；且无法突破系统对单线程栈的硬限制（一般 ≤ 1GB） - 用
std::thread显式指定栈大小（如std::thread(std::stacksize_t{4 * 1024 * 1024}, ...)）可行，但 C++20 才标准化，老标准需平台扩展（pthread_attr_setstacksize） - 真正靠谱的做法：把深度敏感逻辑移出栈——比如把递归改为迭代，或把大中间数据存到
std::unique_ptr或全局static缓存中
递归边界检查、参数合法性校验、以及用 std::stack 替代隐式调用栈，比调栈大小更能根治问题。很多人调了 ulimit 发现还是崩，就是因为没意识到——栈溢出只是症状，失控的控制流才是病根。
