Go 1.25 sync.WaitGroup.Go 怎么用：少写 Add 和 Done，但别拿它替代 errgroup

Go 1.25 给 sync.WaitGroup 新增了一个改动不大但写起来省心的方法：WaitGroup.Go。它解决的不是复杂的并发编排难题，而是日常开发里最常碰到的小痛点：起几个 goroutine 跑任务，等所有任务执行完再往下走。之前写这段逻辑总要手动写 Add、Done 和 go func()，现在能少写几行样板代码，也能减少漏写 Done 引发死锁的排查工作量。

这个变化一句话说清楚：WaitGroup 终于能自己启动任务了

老写法的坑不是难理解，是样板代码太多写起来繁琐。手一快把 Add 放错位置，或者某个分支漏写了 Done，排查起来绕半天摸不到头绪。WaitGroup.Go 直接把「加计数、启动 goroutine、跑完自动减计数」三个操作打包成一个入口，写出来的代码语义特别直白：这是一组要等全部跑完的任务。

var wg sync.WaitGroup

wg.Go(func() {
    refreshCache(ctx, "user_profile")
})

wg.Go(func() {
    refreshCache(ctx, "order_summary")
})

wg.Wait()

读代码的时候你会发现，关注点直接从「怎么维护WaitGroup的计数」落到「这组任务各自要做什么」。对业务代码来说这种小优化特别实用，并发相关的逻辑写得越短，你越容易看清整个生命周期的边界。

为什么 Go 会给 WaitGroup 补这个方法

sync.WaitGroup 本来就是Go生态里最基础的并发等待工具，但过去它只负责计数，不帮你启动goroutine。这个设计弹性很高，可也容易让模板散掉：先调 Add(1)，再开 goroutine，函数里第一行写 defer Done()，最后在外层调用 Wait()。

WaitGroup.Go 本质上就是把社区用了很多年的最通用、最不容易出问题的模板直接固化进了标准库。它没改WaitGroup本身的定位，也没把它做成什么重型任务框架，只是把大家最常写的用法捋得更顺。尤其是缓存预热、批量发通知、并行拉好几份只读数据源这种场景，只要跑完就行不用管单个任务返回值，用它写出来的代码特别清爽。

旧写法怎么迁移，先挑最朴素的任务

改老代码别一上来就全局替换。先找那些没有返回值、不用收错误、没有复杂取消逻辑的地方下手。比如后台同时刷几个互不相关的缓存、并行调两个内部只读接口、批量写几条完全独立的日志，这些场景改起来几乎没什么风险。

// 旧写法
var wg sync.WaitGroup
for _, key := range keys {
    key := key
    wg.Add(1)
    go func() {
        defer wg.Done()
        refreshCache(ctx, key)
    }()
}
wg.Wait()

// 新写法
var wg sync.WaitGroup
for _, key := range keys {
    key := key
    wg.Go(func() {
        refreshCache(ctx, key)
    })
}
wg.Wait()

这里的局部变量 key := key 可以按团队习惯保留，尤其是代码库里还有类似旧写法、读者需要快速确认每轮任务输入时。WaitGroup.Go 只是帮你省掉计数相关样板，不是把闭包、共享变量和任务输入边界全都替你设计好。

哪些代码别硬改成 WaitGroup.Go

最容易踩坑的地方，是硬把 WaitGroup.Go 当成 errgroup 的平替。它本身不支持返回错误，也不会因为某个任务失败就自动停掉其他任务。如果你的逻辑要把错误往上层抛，或者某个任务出问题后要尽快终止整组任务，继续用 errgroup.WithContext 更合适。

• 任务函数需要返回 error：优先选 errgroup。
• 要限制同时跑的goroutine数量：用带缓冲的channel、自己写的任务池或者 errgroup.SetLimit 这类成熟方案。
• 计数由外部事件触发，任务启动和跑完的逻辑不在同一块代码里：老老实实手动写 Add/Done 可读性更高。
• 任务里有可能 panic：先明确恢复策略和日志上报逻辑；官方文档要求传入的函数不应 panic。

最小验证：看 Wait 是否按预期返回

改完代码别光看编译能过就完事。最简单的验证逻辑也没多复杂：准备三类任务，正常跑完的、提前返回的、模拟耗时很久的，确认 Wait() 要等所有任务全跑完才返回，打出来的日志顺序也符合你的预期。再配合 go test -race 检查共享变量的写入情况，不少藏得很深的小问题提前就能揪出来。

func TestWaitGroupGo(t *testing.T) {
    var wg sync.WaitGroup
    var mu sync.Mutex
    done := make([]int, 0, 3)

    for i := 0; i 

这个测试逻辑写起来不费劲，却能帮你确认改完的代码没因为闭包捕获、共享切片读写或者计数时机不对带出啥新bug。线上的生产代码再补上超时控制、日志埋点和指标上报，后面出问题排查起来也省心很多。

相关问题

WaitGroup.Go 是不是必须升级到 Go 1.25 才能用？

是的，这个方法是Go 1.25版本才新增的标准库能力。如果项目还跑在更低的Go版本上，接着用传统的 Add/Done 写法就行，或者自己封装一个差不多的工具函数也行。

WaitGroup.Go 会自动处理 panic 吗？

别把它当成panic处理器。任务逻辑里可能抛panic的时候，你得在业务层自己决定要不要恢复、怎么记日志、要不要让进程退出，别把这些责任丢给WaitGroup。

WaitGroup.Go 和 errgroup 最大区别是什么？

WaitGroup.Go 只负责等所有任务跑完，errgroup 能收集任务抛出来的错误，平时还经常和 context 搭配做取消传播。只需要等全部跑完就用前者，要处理错误、要做取消就选后者。

循环里用 WaitGroup.Go 还需要注意变量捕获吗？

仍然建议看清任务输入从哪里来。新版 Go 已经改善了常见的循环变量捕获问题，但在批量迁移时显式保留局部变量，能让每轮任务用的是哪个值更容易被读者确认。

sync.WaitGroup.Go 的价值不是「新增了一个很炫的 API」，而是把 Go 里经常写的一段并发样板代码变短了。适合用它的地方就用，把多余噪音删掉；要处理错误、取消、限流和复杂生命周期的场景，直接选更合适的工具。这个边界理清楚，迁移才不会把简单逻辑改复杂。