

新闻资讯
行业动态Go中defer按后进先出顺序执行,recover仅在defer函数内直接调用且同goroutine panic时有效;子goroutine panic需在其内部defer+recover处理,无法跨goroutine捕获。
Go 中 defer 不是“注册回调”,而是把函数调用压入当前 goroutine 的 defer 栈,遵循后进先出(LIFO)——最后声明的 defer 最先执行。这和 recover 能否生效直接相关。
关键点在于:recover 只在 defer 函数中调用才有效,且仅对**同一 goroutine 中当前正在发生的 panic** 生效。如果 defer 函数本身没执行、或执行时 panic 已结束、或不在 panic 的 goroutine 里,recover 返回 nil。
defer 按逆序执行:先写后执行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() 后继续执行可能依赖原状态的逻辑(比如原变量已处于不确定状态)子 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.Error 或写 response,导致客户端卡住或收到空响应nil 或已失效),掩盖真实问题真正难的从来不是“怎么写 recover”,而是“在哪一层 recover”“recover 后是否该重试/降级/记录上下文”——这些决策没法靠 defer 语法自动解决。