char buf[1024*1024]一运行就崩是因为Windows默认栈仅1MB、Linux虽默认8MB但函数调用叠加后迅速耗尽，触发0xC00000FD或Segmentation fault；本质是大数组占满栈空间，而非逻辑错误。
为什么char buf[1024*1024]一运行就崩
因为栈空间默认太小——Windows VC++ 默认 1MB，Linux ulimit -s 通常是 8192 KB（8MB），但函数帧里塞一个 1MB 数组，再叠几层调用，立刻触顶。错误码 0xC00000FD 或 Segmentation fault 就是它在喊救命。这不是代码写错，是内存布局常识没对上。
static、std::vector、new 三种解法的区别
它们本质都是把数据从栈挪到别的地方，但位置和管理方式不同：
-
static char buf[1024*1024]：变量进全局/静态区，不占栈，线程不安全，多线程里所有调用共享同一块内存 -
std::vector<char> buf(1024*1024)</char>：对象本身（几个指针+size）在栈上，实际数据在堆上；自动管理生命周期，推荐首选 -
char* buf = new char[1024*1024]：纯堆分配，但必须配对delete[] buf，漏删就是内存泄漏
别用 std::array<char></char> ——它仍是栈变量，和裸数组一样危险。
VS 里改 /STACK 是不是万能钥匙
不是。增大栈只是掩耳盗铃：
立即学习“C++免费学习笔记（深入）”；
- 主线程调大了，
std::thread默认仍只给 2MB，子线程照样崩 - 改到
/STACK:16777216（16MB）后，可能触发 ADO 连接失败或CreateThread失败——底层某些组件对栈大小敏感 - 递归场景下加栈完全无效，栈帧数量翻倍，撑爆只是时间问题
真正该做的，是让大缓冲区彻底离开栈——哪怕只改一行：char buf[1024*1024] → std::vector<char> buf(1024*1024)</char>。
调试时怎么快速确认是不是栈溢出
别猜，用工具交叉验证：
- Linux 下先跑
ulimit -s看当前限制，再gdb ./a.out core后执行bt：如果栈帧数超 500 层，或出现大量重复函数名（比如全是parse_json），基本锁定递归栈溢出 - Windows 下看崩溃弹窗错误码是不是
0xC00000FD，再用 VS 的「调用堆栈」窗口（Alt+7）观察深度 - 临时加
ulimit -s 65536（64MB）测试：程序不崩了，说明确实是栈不够，而非逻辑错误
最常被忽略的点：std::thread 创建的子线程，它的栈独立于主线程，且默认更小——同一段“安全”的代码，在子线程里跑就崩，八成是这个原因。
