Go 怎么用 errgroup 管理一组并发任务的首个错误

Go 里需要并发执行多项工作时，errgroup 适合处理“一个失败，整组尽快停下”的场景。常用写法是 errgroup.WithContext 创建共享上下文，把它传给每个子任务；第一个返回非 nil 错误的任务会触发取消，最后由 Wait 等待所有任务结束并返回首个错误。

关键点不是 errgroup 强行杀掉 goroutine，而是首错后取消共享 Context，子任务在循环、请求或数据库调用处主动检查 ctx.Done() 并返回。只有这样，取消、首错和收尾才会连成一条闭环。

先把首错、取消和收尾分成三条边界

假设一个请求要并发读取用户资料、订单和库存。调用方只关心这次聚合是否成功，因此任一读取失败后，另外两项继续耗时就没有意义。可以用下面的关系理解这段设计：

用 WithContext 建立可取消的并发任务组

下面的示例用三个函数代表不同后端读取。示例重点是控制流：任务只要返回错误，派生上下文就会被取消；其他任务通过 select 观察信号并尽快返回。

package main

import (
    "context"
    "fmt"

    "golang.org/x/sync/errgroup"
)

func loadOne(ctx context.Context, name string) error {
    select {
    case 

闭包里的 name := name 是为了让每个 goroutine 捕获当前迭代值；它和 errgroup 的错误传播是两件事。真正的网络或数据库 API 应该直接接收 taskCtx，例如使用支持 Context 的请求方法，而不是在外层创建一个无法取消的调用。

首个错误如何让其他任务退出

WithContext 只负责发出取消信号，不能中断一段不检查 Context 的纯计算。长循环应在每轮检查 Done，可取消的 I/O 则把上下文传进 API。外部请求本身也可以先套一层 WithTimeout，让超时成为整组任务的取消来源。

func consume(ctx context.Context, values 

因此，“第一个错误”不等于“第一个完成的任务”。成功任务返回 nil 不会触发取消；多个任务几乎同时失败时，哪个错误最终被记录取决于它们返回的时序，调用方不应依赖错误文本的固定顺序。

用 Wait 做统一收尾，不要提前返回

正确的调用顺序是先注册全部任务，再调用一次 Wait。如果在首个错误出现后直接从上层返回，其他 goroutine 仍可能持有连接、写入结果或占用资源。Wait 等待它们真正返回，才是请求生命周期的收口。

如果外层 Context 先超时，Wait 返回的可能是任务主动返回的 context deadline exceeded，也可能是某个任务的业务错误。调用方应根据错误链和业务语义分类处理，不要简单把所有取消都当成服务故障。

常见问题

errgroup 会不会强制杀死其他 goroutine？

不会。它取消派生 Context，具体 goroutine 是否退出取决于任务是否检查 Context，以及所调用的 I/O 是否支持取消。

为什么成功任务完成后，Wait 仍然不返回？

因为至少还有一个已注册任务没有返回。检查它是否卡在不可取消的 I/O、无限循环或等待一个永远不会关闭的 channel。

能不能每个任务使用不同的 Context？

可以保留更具体的子 Context，但它们都应从 errgroup 返回的派生 Context 继续派生；如果绕开它，首错取消就传不到该任务。

参考资料

• golang.org/x/sync/errgroup 官方文档
• Go context 包文档
• Go：取消进行中的操作