Go语言ErrGroup并发错误处理详解

本文深入剖析了Go语言中ErrGroup并发错误处理的核心陷阱与最佳实践，揭示了context取消后Run方法panic的正当性、GoContext与Go在任务取消感知上的本质差异、Wait返回nil却隐含失败的风险，以及WithContext与WithCancel的误用代价；强调ErrGroup并非万能错误收集器，而是依赖开发者对context生命周期的精准把控和任务边界的清晰设计才能安全落地的协调机制——掌握这些细节，才能避免线上服务因goroutine泄漏、错误掩盖或意外panic而崩溃。

ErrGroup.Run 启动任务时 panic：context.Canceled 是正常现象

当 ErrGroup 关联的 context 被取消（比如超时或手动调用 cancel()），后续再调用 eg.Run() 会直接 panic 报 context.Canceled。这不是 bug，而是设计使然——ErrGroup 认为上下文已失效，拒绝接收新任务。

常见错误现象：panic: context canceled 出现在 eg.Run() 调用处，但你没显式 cancel；其实是上游 context 已过期（例如 context.WithTimeout 到期）。

• 务必在调用 eg.Run() 前检查 ctx.Err() == nil，否则直接 panic
• 不要复用已取消的 context 创建新 ErrGroup；每次并发批次应配独立 context
• 如果需要“尽力执行”，改用 eg.Go() + 手动判断 ctx 是否有效，而非依赖 Run()

Go() 和 GoContext() 的选择：何时必须用 GoContext

ErrGroup.Go() 只接受无参函数，不感知 context；ErrGroup.GoContext() 显式传入 ctx，并在内部自动监听取消信号、提前中止 goroutine。两者行为差异直接影响错误传播的及时性。

使用场景：HTTP 请求、数据库查询、文件读写等可能阻塞且支持 context 取消的操作。

• 只要任务函数本身接受 context.Context 参数，一律优先用 eg.GoContext()
• eg.Go() 适合纯 CPU 计算、无 IO、不响应取消的短任务；它不会主动检查 context 状态
• 混用二者时，Go() 启动的任务可能继续运行，即使 context 已取消，导致资源泄漏或错误被掩盖

示例：

eg.GoContext(func(ctx context.Context) error {
    return http.GetWithContext(ctx, "https://api.example.com/data")
})

errgroup.Wait 返回 nil 却仍有子任务失败：检查是否漏了 err 检查

errgroup.Wait() 返回 nil 表示「所有启动的任务都完成了，且没有非 nil 错误被报告」。但它不保证每个 goroutine 都真正执行完毕——如果某个 Go() 任务 panic，而你没 recover，整个程序就崩了，根本走不到 Wait()。

更隐蔽的问题是：多个任务返回错误，但 ErrGroup 只保留第一个非 nil 错误（按完成顺序），其余错误被丢弃。

• 务必在每个 Go() 或 GoContext() 的闭包里显式处理并返回 error，不要只 log
• 不要假设 Wait() 返回非 nil 就代表“有错”，返回 nil 也不代表“全成功”——要结合业务逻辑确认关键路径是否执行
• 若需收集全部错误，不用 errgroup.Group，改用自定义 channel + sync.WaitGroup + slice 存储

WithContext 和 WithCancel 的区别：别在 HTTP handler 里用 WithCancel

errgroup.WithContext(ctx) 返回的 Group 共享原 context；errgroup.WithCancel(ctx) 内部额外调用 context.WithCancel(ctx)，提供一个可主动取消的子 context。但这个取消能力不是免费的。

性能影响：每次 WithCancel() 都新建 context 节点，增加调度开销；在高并发 HTTP handler 中频繁创建，会放大 GC 压力。

• 绝大多数场景用 errgroup.WithContext(r.Context()) 就够了，让请求生命周期自然管理
• 仅当你需要「主动终止部分子任务而不影响父 context」时才用 WithCancel()，例如长轮询中收到客户端断连信号
• 用 WithCancel() 后记得调用返回的 cancel() 函数，否则子 context 泄漏，goroutine 无法退出

ErrGroup 不是错误收集器，它是错误传播协调器。它不帮你捕获 panic，也不合并多个 error，更不保证所有 goroutine 都能优雅退出——这些都得靠你对 context 的理解和对任务边界的清晰划分。

终于介绍完啦！小伙伴们，这篇关于《Go语言ErrGroup并发错误处理详解》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识，快来关注吧！