栈溢出崩溃需先查调用栈深度，Windows默认1MB、Linux约8MB栈空间，递归过深或栈上分配大数组易触发；调试器看bt或Call Stack可定位重复函数名；改用堆分配（如std::vector）和静态分析工具（ASan、Clang Analyzer）提前预警。
看调用栈深度是不是爆了
运行时崩溃弹出 Stack overflow，第一反应不是改代码，而是确认当前线程栈用了多少层。Windows 默认栈大小约 1 MB，Linux 一般是 8 MB，但递归每进一层就压一个栈帧（含参数、返回地址、局部变量），几十层不显眼，上万层基本必崩。
用调试器直接看是最准的：GDB 下运行到崩溃点后输入 bt，VC++ 里按 Alt+7 打开 Call Stack 窗口。如果看到几百上千个重复的函数名（比如全是 quickSort 或 parseNode），基本就是递归失控。
- 递归没设终止条件，或终止条件永远不满足（比如
while (n != 0) { n /= 2; }在n为负时陷入死循环） - 传参错误导致递归“退不出”，例如本该传
n-1却传了n - 尾递归未被编译器优化（
gcc -O2可能优化，但clang或 MSVC 默认不一定开启）
查大数组和对象是不是堆在栈上
局部变量声明了超大数组或重型对象，比如 char buffer[2 * 1024 * 1024]（2 MB），在默认 1 MB 栈下直接炸。这类问题不会出现在调用栈里，但函数一进入就崩，且崩溃位置就在变量声明行附近。
注意：std::vector、std::string、std::unique_ptr 这些内部用的是堆内存，安全；但 std::array、裸数组、大型结构体实例（尤其含内嵌大数组的类）全在栈上。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 把
int arr[1000000]改成std::vector<int> arr(1000000)</int>，或auto ptr = std::make_unique<int>(1000000)</int> - 避免在栈上创建含 1 MB 成员的类实例，可改为指针或
std::shared_ptr - 结构体对齐填充也可能意外放大尺寸，用
sizeof(YourStruct)实测，别靠目测
用编译器选项和工具提前预警
等崩溃再修是被动的。GCC/Clang 支持 -Wstack-protector 和 -fstack-check，能插入运行时栈边界检查；MSVC 的 /GS 也能捕获部分栈破坏，但对纯溢出不敏感。
更实用的是静态分析：Clang Static Analyzer（clang++ --analyze）会标出疑似过深递归或大栈分配；CMake 中加 set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address") 启用 AddressSanitizer，它虽主查堆错误，但在某些栈溢出场景（如局部数组越界）也会报 stack-buffer-overflow。
- AddressSanitizer 对纯栈空间耗尽（如无限递归）不报错，但它能抓到栈上数组写越界——这常是溢出前兆
- 不要依赖
ulimit -s或链接器--stack无脑加大栈，这掩盖问题且可能引发其他兼容性故障（比如 Windows 下改大栈后CreateThread失败） - 单元测试里对递归函数加深度计数断言，比如
assert(depth ，比崩溃后再查快得多
修复后还得验证栈用量是否真降了
改完不能只看“不崩了”，得确认栈占用确实下来了。Linux 下可用 pstack <pid> 查运行中线程栈帧数；Windows 下用 Process Explorer 的 Thread 页面看“Stack Usage”。更底层一点，函数开头加一行：char dummy; printf("stack used: %p\n", &dummy);，对比改前后地址差值（需关闭 ASLR 或固定栈基址才准）。
最容易被忽略的是：多线程环境下，每个线程有自己的栈，主线程改好了，工作线程可能还在用老逻辑；还有 lambda 捕获大对象、协程挂起帧这些隐式栈增长点，它们不会出现在传统递归调用栈里，但一样吃栈。
