Go 1.25 sync.WaitGroup.Go 怎么用：少写 Add/Done，但别忽略 panic 和复用边界

批量写入接口里最常见的一段并发样板，是先 Add、再开 goroutine、最后在函数末尾 Done。代码不长，漏掉一次 Done 却能让 Wait 永远等下去。Go 1.25 新增的 sync.WaitGroup.Go 把“启动任务”和“计数归还”放到同一个入口，能少掉一类配对失误。

旧写法真正容易错在哪里

旧写法本身没有问题，问题在于计数和任务启动分散在多处。下面这段在正常路径能工作，但一旦有人把 Done 移出延迟调用、在分支里提前返回，或者在循环里漏写一次，故障往往只会表现成接口卡住。

var wg sync.WaitGroup

for _, orderID := range orderIDs {
    orderID := orderID
    wg.Add(1)
    go func() {
        defer wg.Done()
        writeOrder(orderID)
    }()
}

wg.Wait()

这里先别急着把所有代码改成新方法。先确认任务函数只是“做完后归还一个等待计数”，没有把取消、错误汇总和限流偷偷塞在同一层。WaitGroup 只回答任务是否结束，不回答任务是否成功。

Go 1.25 的 WaitGroup.Go 把配对关系收进一个调用

WaitGroup.Go 会调度传入的函数并把它作为 WaitGroup 任务登记；函数返回时任务会从计数中移除。对于一批独立写入，代码可以简化成下面这样，读代码的人也能一眼看出“这里启动的是等待组托管的任务”。

var wg sync.WaitGroup

for _, orderID := range orderIDs {
    orderID := orderID
    wg.Go(func() {
        writeOrder(orderID)
    })
}

wg.Wait()

新的入口不会改变并发调度逻辑，也不会替你限制下游数据库连接数。它主要减少的是 Add 和 Done 的人工配对动作。任务数量很大时，仍需要搭配信号量、worker 池或者队列来限制同时运行的工作量。

第一步核对：Wait 前要先建立第一批任务

官方文档明确的边界很重要：当 WaitGroup 为空时，启动任务的 Go 调用需要发生在 Wait 之前。普通批处理场景通常天然满足这个顺序：循环里逐个启动任务，循环结束后再调用 Wait。

func flush(orderIDs []string) {
    var wg sync.WaitGroup

    for _, orderID := range orderIDs {
        orderID := orderID
        wg.Go(func() {
            writeOrder(orderID)
        })
    }

    wg.Wait()
}

不要把 Wait 和“后续还会不会继续往这个空组里加任务”放在同一个模糊的生命周期里混着用。如果一个任务需要再开子任务，文档允许在 WaitGroup 非空时继续调用 Go；但一轮 Wait 完成后准备复用同一个 WaitGroup 时，下一轮的新任务启动动作要等上一轮的 Wait 完全返回之后再执行。

第二步核对：panic 不是 WaitGroup.Go 的恢复策略

这点很容易被“自动 Done”的特性误导。WaitGroup.Go 要求传入的任务函数不能发生 panic；它本身不是一个带异常恢复能力的任务框架。如果写入逻辑会因为第三方输入、网络库调用或者业务分支触发 panic，应该在更合适的边界处理：要么提前把异常分支改成返回 error，要么在任务函数内部用项目已有的异常捕获和告警规则把逻辑包起来。

不要因为新方法写起来更短，就顺手把异常吞掉。真正要做到的是既保证等待逻辑不会挂死，同时让运行失败的信息能被记录和汇总；这通常搭配带锁的错误收集器、专用 channel，或者提前预分配结果位让任务写入就可以实现。

第三步核对：版本边界和兼容层

升级时最稳妥的方案，是先在一个独立的小模块里替换一段完全无关的等待逻辑，跑完现有测试和竞态检测确认没问题之后再逐步铺开。不要把版本升级、任务模型重构、错误处理改造塞进同一次大提交，出了问题很难定位到底是语义差异还是业务路径改动导致的故障。

从旧写法迁移时，先挑这类小场景

适合先替换的场景是：一组互不依赖、没有返回值、只需要统一等全部执行完的任务，比如并行写几个独立缓存、生成多份缩略图、预热几条固定配置规则。这类场景的计数逻辑最清晰，替换前后的行为差异很容易对比验证。

不适合直接替换的场景是：需要超时取消、依赖前一个任务的执行结果、必须按固定顺序收集错误，或者会递归动态派生新任务但团队还没明确生命周期规则的场景。先把任务间的协作协议捋顺，再判断要不要用 WaitGroup.Go，比单纯追求代码行数少更重要。

相关问题

WaitGroup.Go 会自动限制 goroutine 数量吗？

不会。它只负责把任务和等待计数关联起来；限制并发仍要搭配信号量、worker 池或者队列实现。

WaitGroup.Go 里的任务可以调用另一个 Go 吗？

等待组计数还没归零时可以继续添加新任务。要避开的坑是一轮 Wait 已经执行完之后，又在同一个 WaitGroup 上混入上一轮之外的新任务。

为什么任务函数不能直接抛 panic？

官方契约明确要求传入的函数不能触发 panic。需要捕获异常时，沿用项目已有的错误处理和告警边界就行，不要把 WaitGroup 当成异常恢复工具来用。

Go 1.24 项目能直接用 WaitGroup.Go 吗？

不能。该方法从 Go 1.25.0 版本开始提供；需要兼容旧工具链的场景，继续用 Add、goroutine 启动、Done 搭配的原生写法就可以。

核对资料

• Go 官方 sync 包：WaitGroup 和 WaitGroup.Go
• Go 1.25 Release Notes