errgroup.withcontext 是并发错误处理的起点,需传入带 cancel 的 context 并在子任务中显式检查 ctx.err(),否则无法及时中断;wait 仅返回首个非 nil 错误,不汇总全部错误。

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的核心概念和高级技巧!











