recover只在同goroutine的defer中调用才有效；子goroutine需自行defer+recover；仅捕获最近一次未处理panic；无法拦截os.Exit、runtime crash、CGO segfault、OOM等fatal error。
panic 发生后 recover 不生效的常见原因
recover 只在 defer 函数中调用才有效，且必须在 panic 触发的同一 goroutine 中。如果 panic 发生在子 goroutine 里，主 goroutine 的 defer + recover 完全捕获不到。
- 确保
recover()调用写在defer函数体内，而不是 defer 外层 - 子 goroutine 必须自己配
defer+recover()，不能指望外层兜底 -
recover()只能捕获当前 goroutine 最近一次未被处理的 panic，多次 panic 后只取最后一次 - 如果 panic 后程序已调用
os.Exit()或发生 runtime crash（如 nil pointer dereference 且未被 defer 捕获），recover()无机会执行
recover 的典型安全包裹模式
不是所有 panic 都该被 recover；盲目吞掉 panic 会掩盖逻辑错误。真正适合 recover 的场景是：明确知道某段外部输入或第三方调用可能 panic（比如 json.Unmarshal 对非法结构体、反射操作不安全字段），且你能定义清晰的 fallback 行为。
- 把可能 panic 的代码单独封装进函数，用
defer+recover()包裹，不要在整个 handler 或 main 函数顶部加一层“万能 recover” - recover 后建议记录日志，至少包含
recover()返回值（即 panic 参数）和当前堆栈（用debug.PrintStack()或runtime.Stack()） - 不要只写
recover(); return—— 这会让调用方误以为成功，应返回明确错误，例如：return nil, fmt.Errorf("unmarshal failed: %v", r)
func safeUnmarshal(data []byte, v interface{}) error {
defer func() {
if r := recover(); r != nil {
log.Printf("panic during unmarshal: %v", r)
}
}()
return json.Unmarshal(data, v)
}
recover 无法拦截的 panic 类型
Go 的 panic 分两类：显式 panic() 和运行时强制 panic（如除零、空指针解引用、切片越界）。前者可被 recover，后者在某些条件下也可能被捕获，但有严格限制。
-
nil函数调用（var f func(); f()）会 panic，可 recover - 向
nilchannel 发送/接收、关闭nilchannel，可 recover - 但
runtime.Goexit()不触发 panic，recover()完全无效 - CGO 调用中发生的 segfault 或 abort，默认不经过 Go 的 panic 机制，recover 无能为力
- 内存耗尽（
runtime: out of memory）等 fatal error，recover 不起作用
defer + recover 的性能与逃逸注意点
每个 defer 语句都会带来少量开销：它需要在函数栈上注册延迟调用，并在返回前执行清理。虽然单次影响微乎其微，但在高频循环或底层库中滥用会累积可观成本。
立即学习“go语言免费学习笔记（深入）”；
- 避免在 hot path（如每请求都走的中间件顶层）放无差别
defer recover()，尤其当 panic 概率极低时 -
defer中若引用了大对象（如整个 request struct），可能导致该对象无法及时被 GC，产生意外逃逸 - 如果只是想记录 panic 日志，比直接 recover 更轻量的做法是设置
debug.SetTraceback("all")并配合全局signal.Notify捕获 SIGABRT —— 但这属于 crash 后分析，不是运行时防御
