go 中无法通过 recover() 捕获栈溢出（fatal error: stack overflow），因为它是运行时触发的致命错误，而非可恢复的 panic；程序会直接打印堆栈并终止，不存在捕获或兜底处理的机制。
go 中无法通过 recover() 捕获栈溢出（fatal error: stack overflow），因为它是运行时触发的致命错误，而非可恢复的 panic；程序会直接打印堆栈并终止，不存在捕获或兜底处理的机制。
在 Go 中，recover() 仅对显式调用 panic() 或由运行时主动引发的 panic 类型错误（如索引越界、nil 指针解引用）有效。而栈溢出属于底层运行时（runtime）检测到的不可恢复状态——当 goroutine 的栈空间耗尽（例如无限递归未设终止条件），Go 运行时会立即中止当前 goroutine 并打印 fatal error: stack overflow，随后整个进程退出。此时控制流已脱离 Go 的 panic/recover 机制，defer + recover 完全失效。
以下代码演示了为何 recover 对栈溢出无效：
func main() {
defer func() {
if r := recover(); r != nil {
fmt.Println("Recovered:", r) // ✅ 对 panic 有效
}
}()
// 触发 panic —— recover 可捕获
// panic("manual panic")
// 触发栈溢出 —— recover 无法捕获，程序立即崩溃
crashByRecursion(0)
}
func crashByRecursion(n int) {
fmt.Println(n)
crashByRecursion(n + 1) // 无终止条件 → 快速耗尽栈空间
}
⚠️ 注意事项：
- 栈溢出无法预防性捕获：Go 不提供类似 C 的 setjmp/longjmp 或 JVM 的 StackOverflowError 异常捕获能力；这是设计使然，旨在避免掩盖严重逻辑缺陷。
- 根本解决方式是预防：检查递归深度、使用迭代替代深度递归、设置显式递归限制（如传入 maxDepth 参数）、借助 runtime.Stack() 监控栈使用（仅作诊断，非拦截）。
-
生产环境建议：
- 使用 go tool trace 或 pprof 分析栈增长趋势；
- 对关键递归函数添加深度校验（例如 if depth > 1000 { return errors.New("recursion too deep") }）；
- 将高风险逻辑置于独立进程或沙箱中，避免单点崩溃影响全局服务。
总结：栈溢出不是 Go 的“错误类型”，而是运行时强制终止信号。与其尝试“捕获”，不如通过设计约束（如迭代化、深度守卫、测试覆盖率）从源头规避。这是 Go 倡导的“显式优于隐式、简单优于复杂”哲学的典型体现。
