Go语言recover处理多协程panic的方法-Golang-PHP中文网

recover必须在每个goroutine内部调用才有效，主goroutine的defer+recover对子goroutine panic无效；子goroutine panic后静默退出易致资源泄漏，须在每个go函数内前置defer+recover并立即return，推荐用safeGo封装兜底。

go语言recover处理多协程panic的方法

recover 必须在每个 goroutine 内部调用才有效

主 goroutine 的 defer + recover() 对子 goroutine 的 panic 完全无效。这不是 bug，是 Go 的明确设计：panic 和 recover 绑定在单个 goroutine 生命周期内。你看到服务没崩，只是因为子 goroutine 崩溃后静默退出，但资源（如未关闭的 net.Conn、*os.File、未释放的 sync.Mutex）可能已泄漏。

常见错误写法：

go func() { panic("boom") }()
defer func() { recover() }() // 这个 recover 属于主 goroutine，永远拿不到上面那个 panic

正确做法是每个可能 panic 的 goroutine 入口处自己配 defer + recover()：

必须写在 go 启动的函数内部，不能外包
必须在可能 panic 的代码执行前注册 defer（即 defer 语句要出现在 panic 或易 panic 调用之前）
recover 后应立即 return，避免继续使用可能已损坏的状态（比如空指针刚 panic 过，再解引用还会 crash）

用 safeGo 封装避免重复写 defer/recover

手动给每个 go 前加 defer + recover() 易漏、难维护。封装一个通用函数能强制兜底，同时保留堆栈和上下文。

推荐实现：

func safeGo(f func()) {
    go func() {
        defer func() {
            if r := recover(); r != nil {
                log.Printf("panic in goroutine: %v\n%s", r, debug.Stack())
            }
        }()
        f()
    }()
}

注意闭包变量捕获问题：

Backup & Recovery Automation

使用 rClone 实现 OpenClaw 备份与恢复自动化。每日备份至 Google Drive，保留 20 天轮换。

下载

如果 f 依赖外部变量（如 ctx、reqID），需显式传入，例如 safeGo(func() { handle(ctx, reqID) })
不要直接写 safeGo(handle)，否则可能捕获到错误的变量快照
该封装不处理返回值；若需 error 传递，应改用 errgroup 配合外围 recover

errgroup.Group 的 recover 行为与陷阱

errgroup.Group 内部确实有 recover，但它只记录第一个 panic，并在 g.Wait() 时重新抛出——这意味着你仍需在调用 Wait() 处加 defer + recover()，否则整个程序会崩溃。

典型翻车场景：

eg := errgroup.Group{}
eg.Go(func() error { panic("oops") })
if err := eg.Wait(); err != nil { // 这里会 panic，不是返回 error
    fmt.Println(err)
}

安全用法：

调用 Wait() 前必须加 defer func() { recover() }()
多个 goroutine 同时 panic 时，只有第一个被记录，其余静默丢失——这对可观测性是硬伤
建议配合结构化日志 + traceID，在每个 eg.Go 内部也做一次 defer + recover() 打点，确保每次 panic 都有独立记录

recover 捕获值的类型断言必须谨慎

recover() 返回 interface{}，实际类型取决于 panic() 传入的参数。可能是 string、*runtime.Error、自定义 struct，甚至 int。直接用 err.(error) 断言会 panic，尤其当 panic 来自 runtime（如 index out of range）时，其底层类型未导出。

稳妥做法：