Go语言recover保护核心业务模块运行的方法-Golang-PHP中文网

recover必须在defer函数中调用，且defer需位于panic触发点的同一goroutine中、尚未返回前；否则recover返回nil，无法捕获panic。

go语言recover保护核心业务模块运行的方法

recover必须在defer函数里调用，否则返回nil

这是最常踩的坑：直接在普通函数体里写 recover()，它永远返回 nil，起不到任何保护作用。Go只允许在被 defer 包裹的匿名函数或命名函数中调用 recover()，且该 defer 必须定义在 panic 触发点的**同一 goroutine 中、且尚未返回之前**。

常见错误写法：

func risky() {
    recover() // ❌ 无效，不在 defer 内
    panic("boom")
}

正确写法（必须）：

func risky() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("caught panic: %v", r)
        }
    }()
    panic("boom") // ✅ 此时 recover 才能捕获
}

defer 语句要放在可能 panic 的代码之前，顺序不能颠倒
如果函数内有多个 defer，recover() 所在的那个必须是最后一个被执行的（即 LIFO 中最先注册的），否则可能被更早的 defer 提前“消耗”掉栈帧
不要试图在循环里反复注册同一个 defer func(){ recover() }() —— 它只对本轮 panic 有效，且每次注册都增加开销

每个goroutine都要独立加recover，跨协程不传递

Go 的 recover() 是 goroutine 局部的：一个 goroutine 里的 panic，只能被它自己内部的 defer+recover() 捕获。主 goroutine 没加，子 goroutine 加了，主 goroutine panic 还是会崩溃；反之，子 goroutine panic 未被捕获，整个进程仍会退出（除非主 goroutine 显式等待并忽略）。

典型场景是 HTTP handler 或定时任务启了新 goroutine：

GitHub Actions Retry Recovery Audit

审计 GitHub Actions 运行，检测失败后成功的重试恢复模式，量化 flaky 重运行的浪费。

下载

http.HandleFunc("/process", func(w http.ResponseWriter, r *http.Request) {
    go func() { // 子 goroutine
        defer func() {
            if r := recover(); r != nil {
                log.Printf("worker panic: %v", r)
            }
        }()
        processHeavyData() // 可能 panic
    }()
})

主 handler 不需要为子 goroutine 的 panic 加 recover，但子 goroutine 自己必须加
别指望外层 defer 能“罩住”子 goroutine —— 它们是隔离的执行单元
若需统一兜底，可封装启动函数，如 go safeGo(processHeavyData)，其中 safeGo 内置 defer+recover

recover后无法回到panic发生点，业务逻辑需主动设计容错路径

recover() 的作用只是终止栈展开、避免崩溃，并让程序继续执行 defer 函数之后的代码。它不会“回滚”或“重试”，更不会自动修复状态。比如在数据库事务中 panic，recover() 后连接可能已断、临时文件没清理、内存引用已失效。

所以核心模块保护的关键不是“拦住 panic”，而是“拦住之后还能干什么”：

在 recover() 块里做必要清理：tx.Rollback()、file.Close()、mu.Unlock()
明确返回错误或降级响应，而不是假装一切正常继续往下走
避免在 recover() 后继续使用可能已损坏的对象，例如 panic 来自 map assign on nil map，恢复后别再往那个 map 写
若 panic 源于外部输入（如 JSON 解析失败），记录原始 payload 和堆栈，便于复现