如何在 Go 中利用 golang.org/x/sync/errgroup 管理并发任务-Golang-PHP中文网

errgroup.group 比 sync.waitgroup 更适合错误传播，因其内置首次错误即返回机制，支持自动终止未启动任务，并需配合 context 实现可取消并发；零值不可用，须用 new 或 withcontext 初始化；子任务须显式返回 error。

如何在 go 中利用 golang.org/x/sync/errgroup 管理并发任务

为什么 `errgroup.Group` 比裸用 `sync.WaitGroup` 更适合错误传播

直接用 sync.WaitGroup 无法在任意 goroutine 出错时提前终止其余任务，且错误只能靠额外 channel 或共享变量传递，容易漏判或竞态。errgroup.Group 内置“首次错误即返回”逻辑：只要一个子任务返回非 nil 错误，后续调用 Wait() 就立即返回该错误，且未启动的任务不会执行（如果用 Go() 启动），已启动的则继续运行但结果被忽略。

实操建议：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

始终用 eg.Go(func() error { ... }) 启动任务，不要自己起 goroutine 调用 eg.Wait()
若需取消正在运行的任务，必须配合 context.Context —— errgroup.WithContext(ctx) 返回的 group 会在 ctx 取消时自动中断等待，并将 ctx.Err() 作为最终错误
注意：未通过 eg.Go() 启动的 goroutine 不受 group 管理，其错误不会被捕获

如何正确使用 `errgroup.WithContext` 实现可取消的并发请求

HTTP 请求类场景最典型：多个 API 调用需并发发起，但用户可能中途取消，或任一请求失败就应停止等待其余响应。

实操建议：

从 context.WithTimeout 或 context.WithCancel 创建上下文，传给 errgroup.WithContext
每个子函数内必须检查 ctx.Err() 并及时返回，否则即使上下文已取消，goroutine 仍可能继续执行（比如阻塞在 http.Client.Do）
http.Client 本身支持 context，应优先用 client.Do(req.WithContext(ctx)) 而非手动轮询 ctx.Done()

ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
eg, ctx := errgroup.WithContext(ctx)

eg.Go(func() error {
    req, _ := http.NewRequest("GET", "https://api1.com", nil)
    resp, err := http.DefaultClient.Do(req.WithContext(ctx))
    if err != nil {
        return err
    }
    defer resp.Body.Close()
    // ...
    return nil
})

if err := eg.Wait(); err != nil {
    log.Printf("failed: %v", err) // 可能是 context.DeadlineExceeded 或 HTTP 错误
}

`errgroup.Group` 的零值不是安全的，必须用 `new(errgroup.Group)` 或 `errgroup.WithContext`

直接声明 var eg errgroup.Group 得到的是零值，其内部 mutex 未初始化，调用 Go() 或 Wait() 会 panic：fatal error: sync: unlock of unlocked mutex。

实操建议：

永远不要使用零值 errgroup.Group，哪怕只是临时测试
两种安全初始化方式：eg := new(errgroup.Group)（适用于无 context 场景），或更推荐的 eg, _ := errgroup.WithContext(context.Background())（统一接口，预留 context 扩展性）
若误用了零值，panic 发生在第一次 Go() 调用时，而非定义处，容易排查遗漏

当任务不返回 error 时，怎么适配 `eg.Go` 的签名

eg.Go 只接受 func() error 类型函数，但很多操作（如写文件、发消息）习惯返回 error 以外的值，或纯副作用无返回。硬塞 return nil 容易掩盖真实错误。

实操建议：

把副作用封装进闭包，显式处理并返回 error：
避免在闭包里忽略错误（如 os.WriteFile(...); return nil），应检查并传播：if err := os.WriteFile(...); err != nil { return err }
若确实无错误可能（如内存 map 赋值），也应写 return nil 明确语义，不要省略

eg.Go(func() error {
    data := []byte("hello")
    if err := os.WriteFile("/tmp/test.txt", data, 0644); err != nil {
        return fmt.Errorf("write file failed: %w", err)
    }
    return nil // 必须有
})

实际用起来最常被忽略的是 context 传递的完整性——光传了 context 给 errgroup.WithContext 不够，每个子任务内部的阻塞操作（网络、IO、time.Sleep）都得主动响应 ctx.Done()，否则取消信号根本进不去。