Go中defer按后进先出顺序执行，recover仅在defer函数内直接调用且同goroutine panic时有效；子goroutine panic需在其内部defer+recover处理，无法跨goroutine捕获。
defer 语句的压栈顺序决定执行顺序
Go 中 defer 不是“注册回调”，而是把函数调用压入当前 goroutine 的 defer 栈，遵循后进先出（LIFO）——最后声明的 defer 最先执行。这和 recover 
能否生效直接相关。
关键点在于：recover 只在 defer 函数中调用才有效，且仅对**同一 goroutine 中当前正在发生的 panic** 生效。如果 defer 函数本身没执行、或执行时 panic 已结束、或不在 panic 的 goroutine 里，recover 返回 nil。
- 多个
defer按逆序执行：先写后执行 -
defer的参数在语句出现时求值（不是执行时），这点常被忽略 -
recover()必须出现在defer函数体内，且不能被包裹在嵌套函数中（除非显式调用）
recover 必须在 defer 函数中直接调用
下面这段代码无法捕获 panic：
func bad() {
defer func() {
go func() { recover() }() // 在新 goroutine 中调用，无效
}()
panic("boom")
}而正确写法是：
func good() {
defer func() {
if r := recover(); r != nil {
fmt.Println("caught:", r) // 输出 caught: boom
}
}()
panic("boom")
}常见错误还包括：
- 把
recover()放在if外部（未包裹在defer函数体里） - 误以为
defer func(){ recover() }()就够了，但没检查返回值，导致 panic 静默吞掉却无日志 - 在
recover()后继续执行可能依赖原状态的逻辑（比如原变量已处于不确定状态）
panic/recover 不跨 goroutine 生效
子 goroutine 中的 panic **不会**触发主 goroutine 的 defer + recover：
func main() {
defer func() {
if r := recover(); r != nil {
fmt.Println("this won't print")
}
}()
go func() {
panic("in goroutine") // 主 goroutine 不受影响，程序 crash
}()
time.Sleep(time.Millisecond)}
若需处理子 goroutine panic，必须在该 goroutine 内部做 defer+recover：
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("goroutine recovered: %v", r)
}
}()
panic("in goroutine")
}()注意：recover 不能拦截系统级错误（如空指针解引用、除零、栈溢出），这些会导致进程终止，不进入 defer 流程。
defer + recover 的典型误用场景
实际编码中最容易踩的坑不是语法错，而是语义误判：
- 在 HTTP handler 中只 defer recover 但没设置
http.Error或写 response，导致客户端卡住或收到空响应 - recover 后继续 return 原有 error 变量（该变量可能为
nil或已失效），掩盖真实问题 - 嵌套 defer：外层 defer 调用内层匿名函数，而 recover 写在内层——此时仍有效，但调试时容易看漏层级
- defer 闭包捕获了局部变量地址，recover 后继续修改该变量，引发竞态或脏数据（尤其在并发 handler 中）
真正难的从来不是“怎么写 recover”，而是“在哪一层 recover”“recover 后是否该重试/降级/记录上下文”——这些决策没法靠 defer 语法自动解决。
