栈溢出本质是线程栈空间被单次压栈快速耗尽，主因是深度递归或超大局部变量；需通过调用栈深度与帧大小区分二者，并分别采用限制递归深度、转迭代或改用堆分配来修复。
栈溢出本质不是内存总量不够，而是线程栈空间被单次压栈操作快速耗尽。Windows 默认每线程栈仅 1MB，Linux 通常为 8MB（可用 ulimit -s 查看），但真正“压垮”它的，往往是深度递归或超大局部变量——两者机制不同，排查和修复路径也明显区分。
看调用栈模式，快速区分递归失控 vs 局部变量过大
崩溃后用 gdb ./a.out → r → bt（或 VS 中打开「调用堆栈」窗口）：
- 若看到几十上百层重复的 func → func → func…，甚至夹杂 main → func → func，基本锁定为递归失控——终止条件缺失、逻辑错误（如用 == 判定浮点数收敛）、或输入规模远超预期（如 fib(100)）
- 若调用栈只有 2–5 层，但某一层帧大小异常（gdb 中用 info frame 可粗略估算），且函数内定义了类似 char buf[65536] 或 std::array
的对象，大概率是局部变量吃光栈
递归问题：先保终止，再控深度，最后转迭代
不依赖编译器优化（如尾递归），从代码层面加固：
- 每个递归函数必须有可到达的 base case，且所有分支最终都收敛至此；检查边界条件是否覆盖全部输入（例如 n 比 n == 0 更鲁棒）
- 加深度参数限制：例如 void dfs(Node* n, int depth, int max_depth = 1000)，进入时判断 if (depth > max_depth) return;
- 对常见结构（树遍历、DFS、表达式求值），优先手动转迭代：用 std::stack 显式维护待处理节点，把隐式调用栈转为堆上可控容器
大局部变量：一律移出栈，交给堆管理
栈上分配无运行时检查，越界即崩溃。安全做法是主动放弃“栈上大物”：
- 把 int arr[1000000] 改成 std::vector
(1000000) 或 std::unique_ptrptr = std::make_unique (1000000) - 避免值传递大对象：递归中传 std::vector 时用 const std::vector
& ，防止每层拷贝副本 - 结构体含大数组字段？考虑拆分数据与逻辑，或改用指针/智能指针延迟加载
栈溢出是典型的“小疏忽引发大崩溃”，关键在写函数前想清楚：这层调用要压多少字节？这个变量真需要放栈上吗？不复杂但容易忽略。
