Golangerrgroup并发使用详解

本文深入解析了 Go 语言中 errgroup 并发控制的核心陷阱与最佳实践，揭示了 `errgroup.Run()` 在 context 取消时直接 panic 的设计本质而非 bug，并强调必须在调用前主动检查 `ctx.Err() != nil`；明确区分 `Go()`（适用于无阻塞纯 CPU 任务）与 `GoContext()`（推荐用于需响应取消的 IO 操作）的适用场景，警示混用导致的资源泄漏与取消失效风险；同时指出 `Wait()` 并不保证逻辑执行完成、仅返回首个错误、且可能掩盖 panic 或丢失关键错误类型，进而提供收集全部错误的可靠方案——从手动加锁维护错误切片到带缓冲 error channel 的轻量替代，助你写出健壮、可观察、真正符合预期的并发代码。

errgroup.Run() 一调就 panic: context canceled？先检查 ctx.Err() == nil

这不是 bug，是设计使然：errgroup.Run() 在 context 已取消（比如超时到期或手动 cancel()）后直接 panic，不给任何机会。它拒绝在失效上下文中启动新任务。

• 常见错误现象：panic: context canceled 出现在 eg.Run() 调用行，但你没显式调 cancel() —— 实际是上游 context.WithTimeout 到期了
• 必须在调 eg.Run() 前加判断：if ctx.Err() != nil { return ctx.Err() }
• 不要复用已取消的 context 创建新 errgroup.Group；每个并发批次应配独立 context
• 如果想“尽力执行”，别用 Run()，改用 eg.GoContext() + 手动检查 ctx.Err()

Go() 和 GoContext() 到底该选哪个？看任务是否响应取消

Go() 和 GoContext() 行为差异极大，选错会导致资源泄漏、错误被掩盖，甚至 context 取消完全失效。

• GoContext() 显式传入 ctx，内部自动监听 ctx.Done()，并在取消时中止 goroutine —— 适合 HTTP 请求、DB 查询、文件读写等支持 context 的 IO 操作
• Go() 只接受无参函数，完全不感知 context；它适合纯 CPU 计算、无阻塞、不响应取消的短任务（如 JSON 解析、字符串处理）
• 混用风险高：一个 Go() 启动的任务可能还在跑，而 GoContext() 任务已退出，Wait() 返回 nil，但实际有任务卡死
• 第三方库调用（如 http.Client.Do）务必用 http.NewRequestWithContext(ctx, ...)，否则 ctx 超时会被绕过

Wait() 返回 nil 就代表全成功？不一定，得看你怎么写闭包

errgroup.Wait() 返回 nil 仅表示「所有启动的 goroutine 都结束了，且没有非 nil 错误被报告」——但它不保证你写的逻辑真执行完了。

• 如果某个 Go() 闭包里 panic 了，又没 recover，整个程序崩溃，根本走不到 Wait()
• 多个任务返回错误，Wait() 只保留第一个（按完成顺序），其余被丢弃；需在每个闭包里显式 return err，不能只 log.Printf
• 错误类型丢失风险：若你依赖 errors.Is(err, context.DeadlineExceeded) 做重试，但 Wait() 返回的是另一个更早失败的 sql.ErrNoRows，分支逻辑就错了
• 验证方式简单：在闭包开头加 log.Printf("start: %s", url)，确认每条日志都出现且无遗漏

要收集全部错误，别硬扛 errgroup 的“首个错误”语义

errgroup.Group 天然只留第一个错误，这是它的定位。真要审计、上报、聚合全部失败原因，就得换方案。

• 最稳妥：用 sync.WaitGroup + sync.Mutex 保护错误切片 —— 声明 var mu sync.Mutex 和 errs []error，每个 goroutine 结束后 mu.Lock(); errs = append(errs, err); mu.Unlock()
• 轻量替代：用带缓冲的 chan error（容量设为任务数），每个 goroutine 发送错误，主 goroutine for i := 0; i 收集
• 性能注意：高频写错误切片加锁有开销，但比丢错误强；调试时临时用 fmt.Printf 更快
• 典型误用：10 万个本地 os.Stat 还套 errgroup —— 单任务微秒级，调度开销反成瓶颈

最常被忽略的一点：errgroup 不是熔断器，也不是自动恢复器。它不中断正在运行的 goroutine，只广播取消信号；能不能及时退出，全看你有没有在关键路径上检查 ctx.Err() 或 select ctx.Done()。

本篇关于《Golangerrgroup并发使用详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！