如何在Golang中捕获Goroutine中的Panic Go语言并发异常处理方案

goroutine 里 panic 不会传播到主线程

go 的 goroutine 是独立的执行单元，内部 panic 不会自动冒泡到启动它的函数或 main 函数。这意味着：你写了个 go func() { panic("boom") }()，程序不会崩溃，也不会报错——它就静默死了，还可能泄漏资源。

常见错误现象：goroutine 突然不干活了、日志断了、http handler 响应变慢甚至超时，但主程序照常运行，recover 完全没被触发——因为你根本没在那个 goroutine 里放 recover。

• 必须在每个可能 panic 的 goroutine 内部用 defer + recover 捕获
• 不要指望外层函数能“兜住”子 goroutine 的 panic
• 如果用 sync.WaitGroup 等待，panic 后 Done() 可能漏调，导致死等

正确写法：defer recover 必须在 goroutine 内部

不是“外面包一层 recover”，而是每个并发逻辑自己负责自己的异常兜底。典型结构就是 go func() { defer func() { if r := recover(); r != nil { /* 记录 */ } }(); /* 业务代码 */ }()。

使用场景：HTTP handler 启动后台任务、定时器回调、消息队列消费者、数据库连接池健康检查等所有非主线程执行路径。

立即学习“go语言免费学习笔记（深入）”；

• recover 只在 defer 函数中有效，且只对同 goroutine 的 panic 生效
• 别把 recover 放在外部函数里——它对别的 goroutine 无感
• 恢复后建议记录 r（可能是 String、Error 或其他类型），别直接丢弃
• 示例：

  go func() {     defer func() {         if r := recover(); r != nil {             log.Printf("panic in worker: %v", r)         }     }()     doWork() // 这里可能 panic }()

recover 后如何安全退出 goroutine

recover 只是止住 panic 的传播，goroutine 还在运行。如果不清掉上下文、不释放锁、不关闭 channel，可能引发数据竞争或资源泄漏。

性能 / 兼容性影响：反复 panic + recover 是昂贵操作，不该作为控制流；但偶尔兜底比进程崩掉强得多。

• recover 后别继续执行敏感逻辑（比如再写一次数据库）
• 如果用了 context.Context，检查是否已 Done()，及时 return
• 确保所有 defer 注册的清理逻辑（如 file.Close()、mu.Unlock()）仍会执行
• 向结果 channel 发送零值 or 错误前，先判断 channel 是否已 close，避免 panic

用 errgroup 或 worker pool 封装 recover 更可靠

手写每个 go defer recover 容易漏、难维护。用 errgroup.Group 或封装好的 worker 池，能把 recover 统一收口。

参数差异：errgroup.WithContext 自带 cancel 控制，适合有生命周期管理的场景；纯 errgroup.Group 则更轻量。

• errgroup.Group 的 Go 方法内部不自动 recover，你仍需在传入函数里自己加
• 推荐封装一个 SafeGo 工具函数：

  func SafeGo(f func()) {     go func() {         defer func() {             if r := recover(); r != nil {                 log.Printf("safe go panic: %v", r)             }         }()         f()     }() }

• 第三方库如 github.com/oklog/run 也默认不 recover，本质一样——异常兜底永远得在 goroutine 内发生

事情说清了就结束：recover 不是开关，是每个 goroutine 自己的逃生舱门；漏掉一个，就少一道防线。