栈空间小且不可扩展，局部大数组或深度递归会直接导致栈溢出崩溃；应改用堆分配的std::vector或迭代替代，栈仅服务于控制流。
为什么局部大数组会直接崩掉程序
栈内存溢出不是“算错了”，是操作系统在你函数里声明 int arr[1000000] 这种大数组时，发现栈空间不够，直接终止进程——连错误提示都可能被截断，只留个 Segmentation fault (core dumped) 或 stack overflow。Windows 下可能弹窗报错，Linux/macOS 通常就静默挂了。
根本原因是：栈空间默认很小（Linux 一般 8MB，Windows 主线程约 1MB），而且它不能动态增长；而堆内存（new / malloc）按需分配，上限通常是几 GB 起步。
- 别在函数里定义超过几万个元素的数组，尤其别嵌套在递归函数里
- 全局或
static数组虽不占栈，但会进数据段，影响启动时间和内存常驻量，不推荐作为通用解法 - 用
std::vector替代裸数组，它底层走堆，自动管理生命周期，且支持移动语义
std::vector 是最安全的替代方案
std::vector 不是“差不多能用”的替代品，它是 C++ 标准库对这个问题的标准答案。它把内存分配移到堆上，构造/析构自动处理，还能随需扩容（虽然大数组建议预分配）。
常见误用：std::vector<int> v(1000000)</int> 看似没问题，但如果在栈上声明这个 vector 对象本身——对象本身很小（几个指针大小），真正数据在堆上，所以完全安全。
立即学习“C++免费学习笔记（深入）”；
- 初始化时用
.reserve()避免多次 realloc：v.reserve(1000000) - 如果确定大小不变，且追求极致性能，可用
std::unique_ptr<int></int>手动管理，但得自己算 size、调delete[] - 避免
std::array<int></int>—— 它仍是栈分配，编译期就报错或运行时崩
递归深度太大也会触发栈溢出
哪怕没声明大数组，深度过大的递归（比如树高 > 10000 的朴素 DFS）同样耗尽栈帧。每个函数调用至少占几百字节栈空间，累积起来很快超限。
这不是“优化代码就能解决”的问题，是调用模型本身的限制。必须换思路：
- 改用迭代 + 显式栈（
std::stack或std::vector模拟） - 尾递归优化？C++ 编译器几乎不保证，别依赖
- 降低单次栈消耗：把大临时变量（如局部
std::string、std::vector）提到函数外或用引用传入 - 必要时用
pthread_attr_setstacksize（Linux）或SetThreadStackWaste（Windows）调大栈，但这是权宜之计，掩盖设计问题
调试时怎么快速定位栈溢出点
崩溃没堆栈？不是编译器问题，是栈坏了之后调试信息也丢了。得靠预防性手段和工具辅助：
- 加编译选项：
-fstack-protector-strong（GCC/Clang），能早一点捕获栈破坏 - 用
ulimit -s查当前栈限制（单位 KB），ulimit -s 65536可临时调到 64MB 方便测试 - AddressSanitizer（
-fsanitize=address）对堆问题敏感，但对纯栈溢出检测有限；更有效的是valgrind --tool=memcheck --max-stackframe=... - 关键函数入口打日志或设断点，配合缩小输入规模，逐步逼近临界点
真正难的不是“怎么修”，而是意识到：栈不是用来存数据的，是为控制流服务的。一旦开始想“这个数组放栈上应该没问题吧”，就已经踩进坑了。
