堆栈溢出由函数调用过深、局部变量过大或递归失控引发，与new/malloc无关；典型表现为超长调用栈和0xc00000fd或segmentation fault；可通过ulimit -s和gdb bt定位，修复优先采用迭代替代递归、大数组移至堆、减小单帧开销。
堆栈溢出通常不是 new 或 malloc 导致的
堆栈溢出（stack overflow）和堆内存问题（heap corruption）常被混为一谈，但它们触发机制完全不同。堆栈溢出几乎总是因为函数调用太深、局部变量太大，或递归失控——new 分配的是堆，不会直接撑爆栈。
- 典型现象：
Segmentation fault (core dumped)或 Windows 下0xC00000FD错误，且调用栈极长（gdb 中bt显示上百层重复帧） - 常见场景：深度递归未设终止条件、大数组声明在栈上（如
char buf[1024*1024];）、lambda 捕获大量对象导致栈帧膨胀 - 注意：
std::vector、std::string内部数据默认在堆上分配，但其对象本身（几个指针+size）仍在栈上——安全；而std::array<char></char>是纯栈变量，危险
快速定位是否是栈溢出：用 ulimit -s 和 gdb 配合
别靠猜。Linux 下先看当前栈限制，再结合 core dump 分析调用深度。
- 运行前查限制：
ulimit -s—— 默认通常是8192（KB），即 8MB 栈空间 - 崩溃后用
gdb ./a.out core，执行bt：如果帧数 > 1000 或出现明显重复模式（比如全是parse_json→parse_json→ …），基本可断定是递归栈溢出 - 临时放宽限制测试：
ulimit -s 65536（64MB），若程序不再崩溃，说明确实是栈不够，而非逻辑错误
修复栈溢出的三个有效手段
改代码比调系统参数更可靠。优先级从高到低：
- 把深度递归转成迭代：用
std::stack或显式状态变量模拟调用栈，避免函数帧累积 - 大缓冲区移到堆上：
std::vector<char> buf(1024*1024);</char>替代char buf[1024*1024];；或者用std::unique_ptr<char> ptr = std::make_unique<char>(size);</char></char> - 必要时调小单帧开销：避免在递归函数里定义大对象、捕获冗余变量（尤其是 by-value 捕获大结构体），用引用或指针传参
std::thread 默认栈大小可能成为隐藏陷阱
新建线程时，如果不指定栈大小，std::thread 使用系统默认值（Linux 通常是 2MB，远小于主线程的 8MB），此时哪怕主线程跑得好好的，子线程也可能因同样逻辑栈溢出。
立即学习“C++免费学习笔记（深入）”；
- 现象：只在多线程路径下崩溃，且
gdb显示栈帧深度正常（bt只有几层），但报Cannot access memory at address或直接 abort - 验证方式：用
pthread_attr_t查默认栈大小，或在创建线程前加pthread_attr_setstacksize(&attr, 8 * 1024 * 1024); - 更稳妥做法：用
std::thread时不依赖默认，改用std::jthread（C++20）配合自定义栈分配器，或直接用boost::thread提供的栈大小控制
栈溢出真正的麻烦点不在“怎么修”，而在“它不报错——只静默破坏栈上相邻变量，或覆盖返回地址”。一旦出现难以复现的诡异行为（比如某个局部 bool 变量突然变成 true），比崩溃还难查。这时候别急着加日志，先检查所有大栈变量和递归入口。
