局部变量过大导致崩溃是因为栈空间有限，如Windows默认1MB、Linux约8MB，大数组（如int arr[1000000]）会直接触发栈溢出，引发Segmentation fault；应改用堆分配（new/malloc或std::vector）并注意内存管理。
为什么局部变量太大就会崩溃
因为函数栈空间有限，通常几 MB 就顶天了。比如在 Windows 默认线程栈是 1MB，Linux 一般是 8MB，但这是整个函数调用链共用的。一旦你声明一个 int arr[1000000]（约 4MB），还没调用别的函数，main 一进栈就可能直接触发栈溢出（Segmentation fault 或 stack overflow），连错误提示都来不及输出。
这不是编译报错，而是运行时崩溃——编译器根本不管栈够不够，它只管分配符号和偏移；真正分配内存的是 CPU 栈指针寄存器，越界就段错误。
- 常见错误现象：
Segmentation fault (core dumped)、程序启动即崩、Debug 下断点都进不去main - 容易被误判为“内存泄漏”或“野指针”，其实根本没到堆操作那步
- 递归过深也会挤占栈，但这里聚焦「大数组/大结构体」这类静态栈分配场景
把大变量挪到堆上：new / malloc 最直接
栈放不下，就换堆。堆空间由操作系统管理，通常 GB 级起步，只要不真 malloc 几个 GB，基本不会爆。
注意别只改分配位置，还要管生命周期：
立即学习“C++免费学习笔记（深入）”；
- 用
new就得配对delete，用malloc就得free；忘了就内存泄漏 -
std::vector是更安全的选择：内部自动堆分配，析构时自动清理，推荐优先用std::vector<int> arr(1000000)</int> - 避免
new原生数组后传给函数再delete[]—— 调用方和实现方责任不清，易 double-free
示例对比：
void bad() {
int big_arr[2000000]; // 栈上，大概率崩
}
void good() {
std::vector<int> big_arr(2000000); // 堆上，安全
// 不用手动释放
}
用 static 或全局变量绕过栈？谨慎！
把变量声明成 static int big_arr[2000000]，确实不占栈——它进数据段（.bss）。但这不是万能解法，副作用很实在：
- 多线程不安全：所有线程共享同一份内存，如果函数可重入或并发调用，数据会互相覆盖
- 初始化开销隐藏：
static数组若带非零初值（如static int a[1e6] = {1}），编译器可能生成大量初始化代码，拖慢首次调用 - 链接期膨胀：多个翻译单元里都有同名
static大数组，每个都会占一份空间，最终可执行文件变大 - 调试困难：全局生命周期让变量状态难以追踪，尤其在复杂调用链中
只适合单线程、只读、且确定不会重复定义的极简场景（比如查表）。
编译器和链接器能帮忙吗？有限但有用
可以微调栈大小，但属于“治标”，不该作为主要方案：
- g++/clang：用
-Wl,--stack,8388608（Linux）或-Wl,-stack_size,0x800000（macOS）增大线程栈，但不能无限加——系统限制、内存碎片、其他线程受影响 - Windows：用
/STACK:8388608链接选项，或SetThreadStackGuarantee运行时调用（仅限当前线程） - VS Debug 模式下默认栈更小（约 1MB），Release 可能稍大，别靠切模式来“修复”问题
真正该做的，是让代码不依赖大栈空间——哪怕你调高了栈，换个环境、换个线程模型（比如协程）、或者嵌入式平台，立刻打回原形。
最常被忽略的一点：结构体成员里嵌了大数组，比如 struct Buf { char data[65536]; };，这种在栈上传参或局部声明时一样崩。得拆出来单独堆管理，或者用 std::unique_ptr<char></char> 包一层。
