golang如何使用errgroup并发编排_golang errgroup并发任务编排方法

Golang并发编排利器：errgroup.Group的正确打开方式

在Go语言的并发世界里，errgroup.Group 是个既强大又容易用错的工具。它绝不是一把万能钥匙，用对了场景事半功倍，用错了反而会引入新的问题。简单来说，它的核心设计哲学是：要么全成功，要么一个出错就全体撤退。

errgroup.Group 什么时候该用，什么时候不该用

当你需要并发执行多个任务，并且希望其中任何一个任务出错，就立刻取消所有正在执行的任务，同时拿到第一个错误信息时，errgroup.Group 就是标准答案。

但话说回来，它并非适用于所有并发场景。如果任务之间完全独立、互不影响，一个任务的失败不需要影响其他任务，那么直接用 sync.WaitGroup 配合独立的错误处理会更轻量、更清晰。另一个常见的误区是限流：errgroup.Group 本身不具备控制并发数的能力。如果你需要限制最多同时发起5个HTTP请求，就必须额外引入信号量（semaphore）或带缓冲的channel来实现。

基础用法：Go 方法必须返回 error，且不能忽略返回值

这是新手最容易踩坑的地方。errgroup.Group.Go 方法只接受一个签名为 func() error 的函数。常见的错误有两种：一是传入了没有返回值的函数，二是在goroutine内部把错误“吞”掉了。

eg := &errgroup.Group{}
eg.Go(func() error {
    resp, err := http.Get("https://api.example.com/users")
    if err != nil {
        return err // ✅ 错误必须从这里返回，不能仅仅打印日志
    }
    defer resp.Body.Close()
    // 处理 resp...
    return nil // ✅ 即使成功，也必须显式返回 nil
})
if err := eg.Wait(); err != nil {
    log.Fatal(err) // ✅ 所有错误在这里统一处理
}

• 函数体末尾如果忘记写 return nil，会导致编译失败。
• 如果只在函数内部用 log.Printf 打印了错误，却依然 return nil，那么 eg.Wait() 会认为任务成功，从而掩盖真正的问题。
• 需要特别注意的是，当多个任务都出错时，eg.Wait() 只会返回它遇到的第一个非 nil 错误，后续的错误会被丢弃。

带上下文取消：用 WithContext 初始化，别自己 new

想要支持超时控制或手动取消？那么必须使用 errgroup.WithContext(ctx) 来初始化，而不是简单地 &errgroup.Group{}。否则，你启动的goroutine将无法感知到context的取消信号。

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

eg.Go(func() error {
    select {
    case <-time.After(5 * time.Second):
        return errors.New("timeout in task")
    case <-ctx.Done(): // ✅ 现在能正确接收到取消信号了
        return ctx.Err()
    }
})

if err := eg.Wait(); err != nil {
    // 错误可能是 context.DeadlineExceeded，也可能是任务返回的其他错误
    fmt.Println(err)
}

• errgroup.WithContext 返回的第二个 ctx 是一个派生上下文，所有在 Go 函数中进行的I/O操作或select判断，都应该使用这个上下文。
• 手动调用 cancel() 后，正在运行的 Go 函数会在下一次检查 ctx.Done() 时退出，但这并非强制中断，goroutine本身不会被kill。
• 如果任务内部包含没有超时设置的阻塞式系统调用（比如一个不带超时的 http.Get），那么即使context超时了，这个调用也可能卡住。此时需要传入一个配置了超时的 http.Client。

并发限制：errgroup 本身不控制并发数，得自己加信号量

默认情况下，errgroup.Group 是“火力全开”的。给它100个任务，它就会瞬间启动100个goroutine。这对于下游服务来说可能是灾难性的。因此，限制最大并发数是一个常见的需求，而这就需要我们自己在外面套一层“限流器”。

立即学习“go语言免费学习笔记（深入）”；

sem := make(chan struct{}, 5) // 令牌桶，最多允许5个并发
eg := &errgroup.Group{}

for _, url := range urls {
    url := url // 关键：避免循环变量捕获问题
    eg.Go(func() error {
        sem <- struct{}{}        // 获取一个令牌，如果桶满了就阻塞等待
        defer func() { <-sem }() // 用defer确保任务完成后必定释放令牌

        resp, err := http.Get(url)
        if err != nil {
            return err
        }
        defer resp.Body.Close()
        return nil
    })
}

if err := eg.Wait(); err != nil {
    // 处理错误...
}

• 信号量channel的容量就决定了最大并发数。如果容量设为0，程序会立刻死锁。
• 务必使用 defer 来释放令牌，这是保证即使在任务panic的情况下，令牌也不会被永久占用的关键。
• 注意，获取令牌的操作（sem <- struct{}{}）必须放在 Go 函数内部。如果放在循环里、Go 调用之前，会阻塞主goroutine，从而失去并发意义。

真正考验功力的是组合场景：既要实现错误传播，又要支持上下文取消，同时还得做好并发限制——这三者缺一不可。任何一个环节的疏漏，都可能导致程序行为异常，甚至陷入卡死的境地。