Go errgroup 实战：并发扇出时别丢掉错误和取消

聚合接口经常需要同时请求用户资料、订单、库存和推荐数据。手写 WaitGroup 可以等待所有任务，但错误传播和取消处理会变得分散。errgroup.WithContext 更适合这类“多个任务共同服务一次请求”的场景。

为什么不用裸 WaitGroup

WaitGroup 只负责等待，不负责错误返回。你需要额外的 error channel、互斥锁或 once 来收集第一个错误，还要自己通知其它 goroutine 退出。代码一复杂，就很容易出现错误被覆盖、channel 关闭时机混乱、goroutine 泄漏。

errgroup 的核心价值

errgroup 把等待、错误收集和 context 取消放到同一套结构里。任意一个任务返回错误，group 派生的 context 会被取消，其它任务只要监听 context，就能及时停止。

不要忽略下游函数的取消能力

errgroup 只能发出取消信号，真正能不能停下来取决于下游函数是否使用 context。HTTP、SQL、Redis 请求都应使用带 context 的 API，否则取消信号只能停在调用栈外面。

生产场景

适用于一个请求内需要并发读取用户、订单、权益、库存等多个独立数据源的场景。它的目标不是盲目提高并发，而是让失败和取消有统一出口。

关键指标

• 每个扇出任务的耗时分布和失败率
• errgroup 返回的首个错误类型占比
• 请求取消后仍在运行的下游调用数量

常见误区

• 在 goroutine 内写共享 map 或 append 切片引入数据竞争
• 下游函数不接收 context，导致 errgroup 只能取消表层逻辑
• 把非核心依赖和核心依赖放在同一组里导致体验型失败拖垮主流程

落地建议

落地时先把依赖分级。核心依赖放入必须成功的 errgroup，推荐、广告、统计等非核心依赖可单独降级。共享结果推荐按下标或独占变量写入，并配合 go test -race 检查。

代码示例

g, ctx := errgroup.WithContext(ctx)
var profile Profile
var orders []Order

g.Go(func() error {
    v, err := userRepo.Profile(ctx, uid)
    profile = v
    return err
})

g.Go(func() error {
    v, err := orderRepo.ListRecent(ctx, uid)
    orders = v
    return err
})

if err := g.Wait(); err != nil {
    return nil, err
}
return BuildDTO(profile, orders), nil

上线检查

• 所有 goroutine 都使用 errgroup 派生的 ctx。
• 共享变量只在每个任务独占写入，避免数据竞争。
• 下游请求使用 QueryContext、NewRequestWithContext 等 API。