调用栈溢出是同步执行触及线程预设栈空间硬边界导致的一触即溃，无法捕获；主因包括无限/过深递归、超大局部变量、深度调用链及栈大小设置过小，根本解法是重构为迭代、拆分流程或改用异步。
调用栈溢出不是“代码写错了”这么简单，而是同步执行机制触及了操作系统为线程预设的栈空间硬边界。它不报错、不抛异常（在多数语言中），而是一触即溃——程序直接终止，连 try/catch 都拦不住。
栈空间是有限的，且默认很小
Windows 线程默认栈大小约 1MB，Linux 通常为 8MB，但 .NET 和 Java 的托管线程栈往往更保守（如 .NET 默认 1MB）。这个空间要容纳：每个函数调用的参数、局部变量、返回地址、寄存器保存值。一旦嵌套太深或单次分配太大，就撞墙。
- 递归调用每层至少压入几十到上百字节，1000 层就可能耗尽栈
-
Span
这类 ref-like 类型虽不分配堆内存，但每次传参都会复制结构体（约 16 字节）并新增栈帧，深度递归时极易触发溢出 - 声明
int[1000000]这样的大数组作为局部变量，可能单次就占满栈
同步执行无法“暂停”或“让出”，只能一路压栈
异步操作（如 await）能在等待 I/O 时释放当前栈帧，把控制权交还调度器；而纯同步代码没有这种机制。只要逻辑还在执行路径上，栈帧就持续累积，没有任何中间缓冲。
- 无限循环本身不会溢出栈，但无限递归会——因为每次调用都新建栈帧
- 事件处理器里反复触发自身（如按钮点击调自己），本质也是隐式递归
- 属性 setter 中修改自身触发 getter，或 OnPropertyChanged 引发 UI 刷新再触发绑定更新，都可能形成同步调用闭环
调试时看不到完整堆栈，是因为已经没空间打印了
StackOverflowException 发生时，运行时往往连异常对象都构造不完。你看到的“at … at … at …”重复几百行，其实是最后还能挤进去的几帧，真正的调用链早已被覆盖或截断。
- Visual Studio 调试器需关闭“仅我的代码”，否则关键帧被过滤掉
- Linux 下用
gdb加载 core dump 后，bt命令常只显示顶层几帧，需结合info registers和内存分析定位 - .NET 中 StackOverflowException 无法被 catch，只能靠预防和日志提前暴露深层调用路径
根本解法不在“加栈”，而在打破同步深度依赖
增大栈（如 JVM 的 -Xss 或 Linux 的 ulimit -s）只是掩耳盗铃。真正可靠的应对，是重构执行模型：
- 递归改迭代：用显式栈（Stack
）或队列替代调用栈 - 拆分长流程：把一个大同步方法切成多个小步骤，用状态机或 async/await 衔接
- 避免跨层强同步耦合：UI 层不要直接调业务层的深度遍历方法，改用事件或消息解耦
- 警惕“伪安全”写法：像
synchronized(obj) { }这种空块，既不解决竞态，也不防溢出，反而掩盖调用关系
