Go x/sync/errgroup.SetLimit 怎样限制并发任务数

我在批量请求和文件处理里最常遇到的并发问题，不是“能不能开 goroutine”，而是任务一多就把连接、内存或下游服务一起推到峰值。errgroup.Group.SetLimit 的作用很明确：把同时处于活动状态的 goroutine 数量限制在上限以内。提交任务时，Group.Go 会在达到上限时等待空位；配合 WithContext 和 Wait，可以把错误传播、取消和收口放在同一套流程里。

官方文档：https://pkg.go.dev/golang.org/x/sync/errgroup

SetLimit 限制的是同时运行的 goroutine 数量

SetLimit(3) 不会把 100 个任务删成 3 个，也不会自动创建一个持久队列。它只是为当前 errgroup.Group 设置活动 goroutine 上限：前 3 个任务进入执行区，后续调用 Go 的提交方在空位出现前等待。任务结束后，等待中的提交才有机会继续。

我会先把这个关系当成一个准入闸门来理解：任务可以很多，但同时占用的执行槽位有限。这样选上限时，关注的是单个任务的资源占用、下游承载能力和允许的排队时间，而不是机器逻辑 CPU 数量一个孤立数字。

把 SetLimit 放在第一次 Go 之前

最小的批量任务可以这样组织。示例把并发上限放在提交循环前，任务函数内部使用同一个上下文；Wait 负责等待全部已提交任务并返回第一个非 nil 错误。

package main

import (
    "context"
    "fmt"

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

func runBatch(ctx context.Context, jobs []string) error {
    // WithContext 会在某个任务返回错误后取消派生上下文。
    group, ctx := errgroup.WithContext(ctx)
    group.SetLimit(3) // 最多让三个任务同时处于活动状态。

    for _, job := range jobs {
        job := job // 为每次闭包保存当前任务值。
        group.Go(func() error {
            // 任务开始前先响应取消，避免继续接收无意义的工作。
            select {
            case 

这里有一个容易忽略的细节：group.Go 自身可能阻塞，所以如果提交循环所在的 goroutine还承担着读取输入、发送取消或关闭通道的职责，就要避免把这些动作绑在同一个会被闸门卡住的执行路径上。简单批处理可以直接使用上面的结构；更复杂的流水线应把生产、提交和消费的职责拆开。

限制值怎么选，先看资源瓶颈再看吞吐

并发上限不是越大越好。HTTP 请求通常先受下游连接数、服务端限流或响应体内存影响；文件处理可能受磁盘吞吐和压缩 CPU 影响；数据库任务则常常受连接池大小影响。我的做法是先找最窄的资源，再用一个小于或接近该资源容量的上限起步。

如果任务平均耗时差异很大，固定上限只能控制同时运行的数量，不能保证完成顺序或每个任务等待时间。此时可以给任务增加超时、重试和可观测字段，但不要把“SetLimit 已经设置”误认为完整的流量控制方案。

WithContext 让第一个错误收口后续任务

errgroup.WithContext 返回一个 Group 和派生上下文。当 Group 中的函数返回非 nil 错误，派生上下文会被取消；Wait 最终返回错误。已经开始的任务不会被强制杀掉，它们必须在自己的 I/O 调用或循环中检查上下文并尽快退出。

func runWithCancellation(ctx context.Context, jobs []string) error {
    // 派生上下文把首个任务错误传递给仍在工作的任务。
    group, ctx := errgroup.WithContext(ctx)
    group.SetLimit(4)

    for _, job := range jobs {
        job := job
        group.Go(func() error {
            // 把 ctx 传给支持取消的下游调用，不要只在函数开头检查一次。
            if err := handleJob(ctx, job); err != nil {
                return err
            }
            return nil
        })
    }
    // 不在这里自行读取错误通道，统一让 Wait 完成错误收口。
    return group.Wait()
}

func handleJob(ctx context.Context, job string) error {
    // 长循环或分段处理要在循环内部检查取消信号。
    for part := 0; part 

在这个模型里，SetLimit 解决“同时有多少个”，WithContext 解决“出现错误后还要不要继续”，Wait 解决“什么时候对外报告这一批结束”。三者职责不同，不能用其中一个代替另外两个。

Go 和 TryGo 的选择取决于背压方式

Group.Go 在达到上限时等待，因此适合“任务必须提交，但提交速度可以被执行速度拖慢”的场景。Group.TryGo 则只在当前活动数低于上限时启动任务，满载时直接返回 false，适合调用方有自己的队列、丢弃策略或稍后重试逻辑的场景。

func submitIfCapacity(ctx context.Context, group *errgroup.Group, job string) bool {
    // TryGo 不等待空位，调用方必须处理 false，否则任务会被静默跳过。
    return group.TryGo(func() error {
        select {
        case 

还要记住三个边界：负数表示不限制，零值会让新的 Go 任务无法加入；限制值必须在活动任务存在时保持不变；一个 Group 应服务于一个任务集合，不要在一次 Wait 完成后把它当成通用池反复混用。若要分批处理，可以等一个 Group 完成后创建新的 Group，并在外层明确每一批的生命周期。

上线前用这张清单判断并发是否真的受控

• 是否在第一次调用 Go 或 TryGo 前设置了明确的上限？
• 任务内部是否把同一个 context.Context 传给可取消的 I/O 或循环？
• 调用 TryGo 返回 false 时，是否有排队、重试或明确丢弃策略？
• 是否只在最后调用一次 Wait，并把它的错误交给上层处理？
• 任务是否释放响应体、文件、数据库连接等资源，避免“并发数受控但资源不归还”？

常见问题

SetLimit 会限制任务总数吗？

不会。它只限制当前活动 goroutine 数量，任务总数仍由调用方的提交循环决定。

SetLimit 设置为 0 会发生什么？

新的任务不能通过 Go 加入 Group；如果业务需要暂停提交，通常应在调用方控制提交循环，而不是把零值当成通用暂停开关。

任务返回错误后，其他 goroutine 会立即停止吗？

不会被强制终止。WithContext 会取消派生上下文，其他任务必须主动检查或把上下文传给支持取消的操作。

什么时候应该用 TryGo？

当调用方能够处理“当前没有容量”的结果时使用，例如已有有界队列、可接受丢弃或可以稍后重试；如果任务不能丢，使用阻塞式 Go 更直接。