Go errgroup.SetLimit 怎么用：批量调用下游时限制并发、保留取消与错误

批量调用下游接口时，errgroup.SetLimit 适合解决“任务数量很多，但同一时刻只允许少量请求在路上”的问题。它不是 worker pool 的替代品：它把并发门槛放在 g.Go 入口，同时保留 WithContext 的首错取消和 Wait 的错误回收。

比如一个商品聚合接口要查询 120 个 SKU，而供应方只给每个调用方约 12 个并发名额。把 120 个 goroutine 一次放出去，短时间也许更快，随后通常会遇到 429、连接排队或超时堆叠。先把额度压到 8，再看下游的响应时间和错误率，往往是更稳的起点。

先用一个有限并发的最小写法

下面的函数查询一组 SKU。每个位置只由一个 goroutine 写入，调用方在 g.Wait 返回前不会读取结果切片，因此这个写入方式不需要再加一把大锁。

func loadPrices(parent context.Context, skus []string) ([]Price, error) {
	group, ctx := errgroup.WithContext(parent)
	group.SetLimit(8)

	prices := make([]Price, len(skus))
	for i, sku := range skus {
		i, sku := i, sku
		group.Go(func() error {
			price, err := fetchPartner(ctx, sku)
			if err != nil {
				return fmt.Errorf("query %s: %w", sku, err)
			}
			prices[i] = price
			return nil
		})
	}

	if err := group.Wait(); err != nil {
		return nil, err
	}
	return prices, nil
}

group.Go 并不是把所有闭包立即塞进运行队列。当 8 个函数仍在运行时，下一次 group.Go 会在入口处等到有空位。这一点很关键：限制发生在提交阶段，内存里不会先积压一大串已经启动、只是等待网络的请求。

限制不是写死在线程数上，而是从下游预算倒推

SetLimit 的数字首先是下游资源预算，不是“这台机器有几核”的缩写。可以把选择过程压缩成三件事：

1. 确认供应方、数据库或内部服务给出的并发配额；没有明确配额时，先用保守值做小流量观测。
2. 查看单次调用的超时和平均耗时。上限越大，同时占用的连接、文件描述符和等待时间越多。
3. 为重试留下余量。若每个子任务内部还会重试，8 个并发不等于每秒只有 8 次请求。

上例的 8 只是示例。若合作方明确允许 12 个并发，而同一个进程还会被其他入口使用 4 个名额，那么批处理设为 6 到 8 更容易留出缓冲。这个数应进入配置，并在日志里带上批次大小、实际并发和下游状态码，后续调小或调大才有依据。

三种写法放在一起看，边界会更清楚

如果需求是常驻消费者、持续接收任务、按优先级调度，worker pool 或消息队列会更贴切。errgroup 更像“一次请求或一次批处理的临时协作组”：创建、启动一批函数、等待结果、结束。

WithContext 和 SetLimit 是一组，但它们解决的不是同一件事

SetLimit 管的是数量；WithContext 管的是生命周期。组内任意函数返回非空错误时，派生的 ctx 会被取消；随后还没有开始的工作不再应继续推进，已经发出的请求则要靠 fetchPartner 真正把这个 ctx 交给 HTTP、数据库或 RPC 调用。

下面这种写法看似用了 WithContext，却让取消停在表面：

group.Go(func() error {
	// 这里没有使用派生 ctx，外部失败后请求仍可能继续等待到超时。
	return fetchPartner(context.Background(), sku)
})

应把派生上下文传下去，并给客户端设置合理超时。取消不是强行终止 goroutine 的开关；下游调用若忽略上下文，组只能等它自己结束。

SetLimit 的两个边界：不要运行中改，也别传 0

官方文档明确要求：有活动 goroutine 时不要修改限制值。实际服务里不要尝试根据瞬时指标对同一个 Group 反复 SetLimit；为每个批次在启动前确定一个值即可。

SetLimit(0) 会让之后的 Go 调用一直等下去，而负数表示不设限制。把配置直接转换为整数前，应在配置加载时拒绝 0 和意外负数，避免一次上线把批处理挂住。

TryGo 适合拒绝或降级，不适合无声丢掉批次

TryGo 在没有空位时立即返回 false，适合“能拿到实时价格就展示，否则用缓存值”的请求路径。它不等待，但也不会替你保存任务。

if !group.TryGo(func() error {
	return refreshCache(ctx, sku)
}) {
	return cachedPrice(sku), nil
}

若这是对账、导入或必须处理完的批次，false 后不能悄悄跳过。应明确进入重试队列、记录未处理项，或改用 Go 等待名额。

落地时把并发预算放在一个明确边界

• 把限制配置在调用下游的那一层，不在每个叶子函数里各设一个数字。
• 错误要带上 SKU、租户或批次标识，方便判断是单项数据问题还是下游整体波动。
• 重试、退避和并发上限一起评审；单个子任务的重试次数也会放大下游压力。
• 批次结束后只从 Wait 的结果继续向外返回，不在尚未结束时读取部分成功数据当成最终结果。

把这几个边界守住，errgroup.SetLimit 就能把“批量调用很容易突然冲高”的风险变成一个可测、可调、可回退的参数。

延伸问答

errgroup.SetLimit 能限制每秒请求数吗？

不能。它限制的是同时处于活动状态的函数数量。调用很快结束时，一秒内仍可能发出很多请求；需要控制速率时，应在入口再配合限速器，并分别观测并发和请求速率。

首次错误后，已经开始的任务一定会马上结束吗？

不一定。WithContext 会取消派生上下文，但正在运行的代码是否尽快返回，取决于它有没有把这个上下文传给可取消的网络、数据库或 RPC 调用。

一组任务结束后，还能继续用同一个 Group 吗？

不建议。errgroup 的文档要求不要把同一个组复用于不同任务。每次批处理新建一组，限制值和上下文边界都更清晰。

相关阅读

• Go 升级到 1.22 后循环变量还会踩坑吗：go.mod 版本和回归检查
• Go singleflight 怎么合并同一请求：缓存失效时别让 500 个请求一起回源
• Go HTTP Client 为什么频繁建连接：Response.Body 没读完和没关闭的排查
• Go 1.25 sync.WaitGroup.Go 怎么用：少写 Add/Done，但别忽略 panic 和复用边界

核对资料

• Go x/sync/errgroup 官方文档：WithContext、Go、SetLimit、TryGo 与 Wait 的行为说明。