栈溢出不是C++异常，无法用try/catch捕获，而是操作系统级崩溃；必须通过递归深度校验、大对象堆分配、显式栈模拟等手段预防，而非依赖尾递归优化或增大栈空间。
栈溢出不是“异常”而是系统级崩溃，std::stack_overflow根本不存在，try/catch完全捕获不到；它本质是操作系统在栈指针越界时直接终止线程，所以不能靠“兜底”，只能靠提前预防和结构替换。
递归深度失控：加计数器比改编译器参数更可靠
看到 gdb 的 bt 输出里几百行重复函数名（比如全是 parse_node），基本就是递归过深。此时增大栈（如 Windows 用 /STACK:16777216，Linux 用 ulimit -s 16384）只是掩耳盗铃——换一台机器、开一个新线程、或输入稍大一点，照样崩。
- 在递归函数签名里显式加
int depth参数，入口处检查：if (depth > 1000) throw std::runtime_error("recursion too deep"); - 不要用全局变量计数，避免多线程冲突和重入问题
- 阈值别硬写死 1000，应结合实际栈帧大小估算：比如每个调用占 256 字节，1MB 栈 ≈ 4000 层，留 30% 余量设为 2800 更稳妥
- 这个检查必须放在函数最开头，否则还没走到判断就已压栈失败
大局部变量：static 或 new，别赖栈
写 char buffer[1024 * 1024]; 这种代码，一进函数就压 1MB，比递归还猛。Windows 默认栈才 1MB，Linux 虽默认 8MB，但线程多时很快耗尽。
- 如果变量生命周期只在函数内，且大小固定，改用
static char buffer[1024 * 1024];—— 它存在数据段，不走栈 - 如果大小运行时确定，必须用
std::vector<char> buffer(size);</char>或new char[size]，手动管理或依赖 RAII - 禁用
alloca()处理大内存，它也是栈分配，且无失败返回机制 - Clang/GCC 加
-Wstack-protector可在编译期警告超大栈分配
无法消除的递归：用 std::stack 模拟调用栈
树遍历、表达式求值、回溯搜索这类逻辑天然递归，硬改成循环易错且可读性差。这时应放弃“函数调用栈”，改用堆上容器模拟：
立即学习“C++免费学习笔记（深入）”；
- 把原递归中要传的参数（如节点指针、状态标志、临时计算值）打包成结构体，
push到std::stack<myframe></myframe> - 用
while (!stack.empty())替代函数调用，pop后处理，需要“递归子调用”时再push新帧 - 注意：别在循环里无条件
push，必须有明确退出条件，否则变成无限循环+内存涨满 - 比起递归，这种方式栈空间恒定（只占几个指针），但堆内存用量上升，需确认堆足够
尾递归优化不可信：别把它当解药
C++ 标准不保证尾递归优化，gcc/clang 只对极简形式（如 return f(x-1);，无中间计算、无析构、无 try-block）在 -O2 下可能优化。现实中带 std::string 参数、std::vector 局部变量、或 return a + f(x-1); 的写法，100% 不优化。
- 用
objdump -d或 Compiler Explorer 看汇编，确认是否真变成了jmp而非call - 一旦开启调试（
-g）、关闭优化（-O0），尾递归一定不生效——而你调试时恰恰最需要它生效 - 把程序可靠性押在编译器行为上，等于埋雷；防御性设计必须独立于优化开关
真正容易被忽略的是：栈溢出常发生在“看似安全”的地方——比如模板递归展开、lambda 捕获大对象、甚至 std::function 构造时隐式拷贝。只要涉及栈上压入数据，就得问一句：它最大可能吃掉多少字节？有没有替代路径？
