一项并发任务失败后如何让兄弟任务收敛：用 errgroup 组织首错与取消

当一组 Goroutine 共同完成一个请求时，真正棘手的不是“怎么启动”，而是某个任务失败以后，兄弟任务是否会停、调用方是否能拿到明确错误。只用 sync.WaitGroup 能等待结束，却不会替你传播错误或取消任务。需要这两条收敛链时，可以用 errgroup.WithContext：任务返回错误，派生 Context 被取消；g.Wait() 等全部已启动任务结束后返回一个错误。

本文先给结论：用一个 group 管理同一项工作，用派生 ctx 传入每个任务，把 ctx 继续交给真正执行 I/O 的 API；任务内部同时检查取消，最后只在调用方读取 Wait 的返回值。

先看清 WaitGroup 与 errgroup 的边界

WaitGroup 解决的是“还有多少项工作没有完成”，errgroup.Group 则把任务函数改成 func() error，额外负责错误传播。它不是一个会自动杀死 Goroutine 的终止器：任务能否尽快结束，仍取决于函数有没有监听 ctx，以及底层依赖是否支持取消。

因此，下面的目标不是收集所有错误，而是为一次整体工作选择一个可处理的失败结果：先返回的非 nil 错误成为 Wait 的返回值；其他任务收到取消后应尽快返回。若业务需要完整错误列表，应另外设计错误聚合，不要误以为 errgroup 会自动保留全部错误。

用 WithContext 把首错变成兄弟任务的取消信号

核心写法是先派生 group 和 ctx，再把同一个 ctx 传给每个任务。以下示例模拟并行读取多个分片：其中一个分片失败时，其他分片不再继续接收新工作。

func loadAll(parent context.Context, ids []string) error {
    g, ctx := errgroup.WithContext(parent)
    for _, id := range ids {
        id := id
        g.Go(func() error {
            if err := ctx.Err(); err != nil {
                return err
            }
            return loadOne(ctx, id)
        })
    }
    return g.Wait()
}

这里的关键是“同一项工作只建一个 group”。不要为每个子任务单独建 group，也不要在外层用一个无关的 Background 覆盖 ctx，否则首错无法传播到兄弟任务。

把 ctx 传到真正执行 I/O 的函数

最常见的假收敛是只在任务入口判断一次 ctx.Err()，随后调用一个不接收 Context 的阻塞函数。这样外层虽然已经取消，HTTP 请求或数据库查询仍可能继续占用资源。

让取消信号穿过完整调用链。例如 HTTP 请求应使用 http.NewRequestWithContext(ctx, ...)，数据库访问应选择带 Context 的查询方法；拿到响应后仍要关闭 Body，数据库 rows 也要在对应作用域释放。

func loadOne(ctx context.Context, id string) error {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet,
        "https://api.example.test/items/"+id, nil)
    if err != nil {
        return err
    }
    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        return err
    }
    defer resp.Body.Close()
    if resp.StatusCode >= http.StatusBadRequest {
        return fmt.Errorf("load %s: %s", id, resp.Status)
    }
    return nil
}

结果写入与收尾怎么判断

如果多个任务把结果写入同一个 map 或切片，先按索引分配独立槽位，或用互斥锁保护共享结构；errgroup 负责协作，不会替你消除数据竞争。任务返回后，调用方统一处理：

if err := loadAll(ctx, ids); err != nil {
    if errors.Is(err, context.Canceled) {
        // 上游主动取消，通常不当成业务失败
        return err
    }
    return fmt.Errorf("load items: %w", err)
}
return nil

还要区分两类取消：如果父 ctx 先超时，返回值可能就是 deadline；如果某个任务先返回业务错误，group 派生 ctx 会被取消，最终由 Wait 返回首个非 nil 错误。不要用 Goroutine 数量立即归零作为唯一证据，正确的收尾点是 Wait 已返回，且每个任务都从自己的函数返回。

常见问题

errgroup 会返回所有错误吗？

默认不会。Wait 返回一个非 nil 错误，工程上通常把它作为本次整体工作的失败原因；要保留多个错误，需要另行设计并发安全的收集器。

任务不支持 Context 时怎么办？

无法强制一个不支持取消的阻塞调用立刻停止。可以把它隔离到更小的边界、设置依赖自身的超时，或更换支持 Context 的 API；不要用关闭无关 channel 的方式假装已经取消。

总结：errgroup 的价值是把“首错—取消—统一等待”连起来，但真正的资源释放责任仍在任务函数和底层 I/O。先确定 group 的工作边界，再让 ctx 穿过每一层，最后以 g.Wait() 的返回值做一次明确收尾。

参考：errgroup 官方文档；Go 官方 Pipeline 与取消说明。