Go语言errgroup使用与错误处理详解

本文深入解析了Go语言中errgroup包在并发错误处理中的关键用法与常见陷阱，强调`errgroup.WithContext`并非简单的语法糖，而是实现“任一失败即整体失败+及时中断”的必要起点；它要求开发者主动传入可取消的context、在每个子任务中显式检查`ctx.Err()`以避免goroutine泄漏，并清醒认知其“只返回首个错误”的设计本质——既不自动汇总全部错误，也不强制终止其余协程，真正的健壮性取决于对上下文传播的全程把控和对每处阻塞点的精细响应。

errgroup 不是“自动收集所有错误”的银弹，它只返回第一个非 nil 错误，且默认不取消其余 goroutine —— 想靠它实现“任一失败即整体失败 + 及时中断”，必须手动启用 Context。

errgroup.WithContext 是并发错误处理的起点

不用 WithContext，errgroup.Group 的 Go 方法启动的 goroutine 完全独立，哪怕某个提前 panic 或返回 error，其余任务照常运行，直到全部结束才返回第一个 error。这在超时控制、资源泄漏场景下很危险。

正确做法是传入带 cancel 的 context.Context：

ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
<p>g, ctx := errgroup.WithContext(ctx)
g.Go(func() error {
return doSomething(ctx) // 所有子任务必须检查 ctx.Err()
})
if err := g.Wait(); err != nil {
// 可能是 doSomething 返回的 error，也可能是 ctx.DeadlineExceeded
}
</p>

• 所有子任务函数里必须显式检查 ctx.Err() 并提前退出，否则 cancel 不起作用
• WithContext 返回的 ctx 是派生上下文，自带取消信号传播能力
• 别直接用 context.Background() 初始化 Group，那等于放弃控制权

子任务中忽略 ctx.Err() 会导致 goroutine 泄漏

常见错误是写成这样：

g.Go(func() error {
    time.Sleep(10 * time.Second) // 模拟耗时操作
    return errors.New("done")
})

如果外部 context 已超时（比如 3 秒），这个 goroutine 还会继续睡满 10 秒，期间无法被中断 —— errgroup 等它自己结束或出错，但不会主动 kill。

• 必须把阻塞调用包在 select 里监听 ctx.Done()
• I/O 类操作（如 http.Get、db.Query）优先用支持 Context 的版本（http.DefaultClient.Do(req.WithContext(ctx))）
• 纯计算逻辑需定期检查 if ctx.Err() != nil { return ctx.Err() }

Wait 返回的是第一个非 nil 错误，不是全部错误

errgroup 的设计目标是“快速失败”，不是“汇总错误”。即使 5 个 goroutine 全部出错，g.Wait() 只返回最先发生的那个 error 值。

• 如果需要收集全部错误，得自己维护一个 sync.Mutex + []error 切片
• g.Wait() 返回 nil 仅表示所有任务成功，不代表没发生任何错误（比如某个任务 panic 了但没 recover，整个程序就挂了）
• 不要依赖 g.Wait() == nil 来判断“所有子任务都执行完了”，panic 或未捕获异常会让部分 goroutine 消失而不影响返回值

真正难的不是调用 errgroup.Go，而是让每个子任务对 Context 敏感、对取消可响应——这要求你深入每处阻塞点，而不是只在入口加一行 WithContext。

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~