Go语言怎么在匿名协程中规范编写recover代码-Golang-PHP中文网

recover必须在可能panic的goroutine内部defer中直接调用，且需检查返回值处理；它无法捕获其他goroutine的panic，也不能替代常规error处理。

go语言怎么在匿名协程中规范编写recover代码

recover 必须在 defer 中调用，且只能捕获当前 goroutine 的 panic

Go 的 recover 不是全局异常处理器，它只对**同一 goroutine 中、同一 defer 链内**发生的 panic 有效。匿名协程（go func() { ... }()）是独立的 goroutine，主 goroutine 的 defer 完全无法捕获它的 panic —— 这是最常见的误用起点。

所以规范写法的第一铁律：每个可能 panic 的匿名协程，都必须在内部自己 setup defer + recover。

错误写法：defer recover() 放在主函数里，指望它拦住子 goroutine 的 panic → 完全无效
正确位置：panic 可能发生的 goroutine 内部，且必须在 defer 中调用 recover()
注意：recover() 必须紧跟在 defer 后，不能包在另一个函数里再调用（比如 defer func() { recover() }() 是 OK 的，但 defer doRecover() 且 doRecover 里调 recover() 就失效 —— 因为执行时机和栈帧不匹配）

recover 后要显式处理 err，不能只调用不检查返回值

recover() 返回 interface{}，仅当当前 goroutine 正处于 panic 中时才非 nil；否则返回 nil。很多同学写了 defer recover() 就以为万事大吉，其实什么都没捕获到，panic 仍会向上传播并终止该 goroutine（日志都不留一条）。

必须显式判断返回值，并做有意义的处理：

记录日志（至少包含 panic 值和堆栈），推荐用 debug.PrintStack() 或 runtime/debug.Stack()
避免裸 panic(v) 二次 panic；如需重抛，应封装为新错误或带上下文再抛
不要忽略返回值：写成 if r := recover(); r != nil { ... }，而不是 recover(); // 忽略返回值

示例片段：

GitHub Actions Retry Recovery Audit

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

下载

go func() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("panic in worker: %v", r)
            debug.PrintStack()
        }
    }()
    // 可能 panic 的业务逻辑
    riskyOperation()
}()

recover 无法捕获 runtime 错误（如 nil pointer dereference）的“全部上下文”

虽然 recover 能截住 panic，但它拿不到完整的 panic 堆栈（尤其跨函数调用链较深时，debug.Stack() 默认只输出当前 goroutine 的栈，且不包含 panic 发生点的精确文件行号）。更麻烦的是：像 nil pointer dereference、slice bounds out of range 这类 runtime panic，在 recover 后仅能得到类似 runtime error: invalid memory address or nil pointer dereference 的字符串，没有原始调用路径。

建议搭配 runtime/debug.Stack()（比 debug.PrintStack() 更可控，可捕获并返回字节流）
若需精准定位，应在关键入口加防御性检查（如 if x == nil { return errors.New("x is nil") }），把 panic 转为可控 error
注意：在 defer 函数中调 runtime.Caller(0) 拿到的是 defer 所在函数的 PC，不是 panic 点 —— 所以别试图靠 Caller 推断 panic 位置