如何使用Golang进行并发错误处理_Golang并发错误捕获与恢复方法

goroutine 中 panic 无法被外部 defer 捕获，必须在内部用 defer+recover 处理；errgroup.group 可聚合显式 Error 但不捕获 panic；向 channel 发送时 panic 会导致死锁，需先 recover 再 send 或用超时机制。

goroutine 中 panic 无法被外部 defer 捕获

Go 的 goroutine 是独立的执行流，内部发生的 panic 不会传播到启动它的 goroutine，外部的 defer + recover 完全无效。这是并发错误处理最常踩的坑——你以为加了 recover 就安全了，其实 panic 已经让那个 goroutine 静默退出。

正确做法是在每个可能出错的 goroutine 内部做错误兜底：

• 必须在 goroutine 函数体第一行就写 defer func() { if r := recover(); r != nil { /* 记录日志或通知 */ } }()
• 不要依赖父 goroutine 的 recover，它对子 goroutine 的崩溃无感知
• 如果 goroutine 承担关键任务（如消息消费、定时任务），recover 后建议主动退出或重试，避免状态不一致

使用 errgroup.Group 统一收集 goroutine 错误

errgroup.Group 是标准库 golang.org/x/sync/errgroup 提供的工具，能自然地把多个 goroutine 的错误聚合起来，比手写 channel + select 更简洁可靠。

典型用法：

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

g, _ := errgroup.WithContext(ctx) for _, task := range tasks {     task := task // 防止循环变量复用     g.Go(func() error {         return doSomething(task)     }) } if err := g.Wait(); err != nil {     // 至少一个 goroutine 返回了非 nil error     log.Println("some task failed:", err) }

• errgroup.Group 在第一个 error 返回时就会取消其余 goroutine（需传入带 cancel 的 ctx）
• 它只捕获显式返回的 error，对 panic 依然无能为力，所以仍需在 Go 函数内加 recover
• 若需区分哪个 task 出错，建议在 error 中带上标识，比如 fmt.Errorf("task %s failed: %w", task.ID, err)

channel 发送 panic 导致的死锁

当 goroutine 在向 unbuffered channel 或已满的 buffered channel 发送数据时 panic，且没有被 recover，该 goroutine 会直接终止，但 channel 发送操作尚未完成——这会导致接收方永远阻塞，引发死锁（runtime error: all goroutines are asleep）。

• 避免在可能 panic 的路径上直接向 channel 发送：先判断、先 recover、再 send
• 使用带超时的发送：select { case ch
• 更稳妥的方式是把结果和 error 封装进结构体，统一通过 channel 传递，由接收方检查 error 字段

context.WithCancel 被意外关闭导致“假失败”

很多人用 errgroup.WithContext 或手动管理 context 时，会在任意 goroutine 出错后调用 cancel()，但没注意：cancel 本身不区分错误类型——网络超时、业务校验失败、甚至日志写入失败都会触发全局退出。

• 不是所有 error 都该 cancel 整个 group；例如某个 task 因临时限流失败，其他 task 仍可继续
• 可自定义错误分类：if errors.Is(err, ErrTransient) { continue }，仅对 ErrCritical 调用 cancel
• 务必确保 cancel 函数只被调用一次，重复调用虽不 panic，但会让后续 context.Done() 立即返回，干扰正常流程

并发错误处理真正的难点不在语法，而在于区分哪些错误该隔离、哪些该传播、哪些该忽略——这些决策藏在业务语义里，代码只是执行者。