Go 1.25 WaitGroup.Go 实战：少写 Add/Done，但别把错误处理弄丢

这两天看 Go 1.25 相关讨论，sync.WaitGroup.Go 被问得挺多。它看起来只是给 Add、go、Done 包了一层，但我建议你别把它当成“语法糖”一笔带过。生产代码里，很多并发 bug 不是什么高深模型没想通，而是某个分支忘了 Done，或者 Add 写在 goroutine 里面，压测时偶尔炸一次。

这篇我按平时 code review 的视角讲：WaitGroup.Go 适合改哪些代码，不适合替代什么，以及团队升级 Go 版本后怎么落地。

先看旧写法的问题

传统写法大家都熟：

var wg sync.WaitGroup

for _, job := range jobs {
    job := job
    wg.Add(1)
    go func() {
        defer wg.Done()
        process(job)
    }()
}

wg.Wait()

这段代码本身没错，但它有几个很容易在项目里扩散的问题。

第一，Add(1)、defer Done() 是重复模板。模板越多，越容易在某次“快速补逻辑”时漏掉。第二，新人经常把 wg.Add(1) 写进 goroutine 里面，主 goroutine 可能先跑到 Wait()，这个 bug 不一定每次复现。第三，一旦函数里混入多层条件分支，Done 是否一定执行，需要 reviewer 花额外精力确认。

WaitGroup.Go 的价值，就在于把这个固定动作收起来，让代码把注意力放回真正的业务并发单元。

WaitGroup.Go 到底做了什么

新的写法大概是这样：

var wg sync.WaitGroup

for _, job := range jobs {
    job := job
    wg.Go(func() {
        process(job)
    })
}

wg.Wait()

它表达的意思很直接：给这个 WaitGroup 增加一个任务，并在新 goroutine 中执行函数，函数结束后任务完成。这样 Add 和 Done 的相对顺序就不再靠人肉维护。

我喜欢它的地方不是“少写两行”，而是少了一个并发代码里最常见的手滑点。并发代码最怕的就是看起来都懂，实际某个细节一乱，线上才提醒你。

不要把它当成 errgroup

这里是重点：WaitGroup.Go 不返回 error，也不会帮你做 context 取消，更不会把第一个错误传回主流程。

如果你的逻辑只是“并发跑一批互不影响的任务，最后等它们都结束”，WaitGroup.Go 很合适。比如刷新多个本地缓存、并发预热多个只读数据块、启动几个独立的后台采集任务。

但如果你的需求是“任意一个任务失败就取消其他任务，并把错误返回给调用方”，那就别硬塞给 WaitGroup。这种场景继续用 errgroup.Group 更清楚。

g, ctx := errgroup.WithContext(ctx)

for _, job := range jobs {
    job := job
    g.Go(func() error {
        return process(ctx, job)
    })
}

if err := g.Wait(); err != nil {
    return err
}

我的经验是：只等待，用 WaitGroup.Go；要错误传播、取消、失败收敛，用 errgroup。这个边界写进团队规范里，后面会省很多争论。

panic 边界要说清楚

还有一个坑：不要以为 WaitGroup.Go 会帮你吞掉 panic。它不是一个 recover 框架。官方文档也强调传入的函数不应该 panic。

生产里如果这个 goroutine 属于后台任务，panic 是否允许打崩进程，要看你的服务策略。很多业务服务里，我更倾向于在任务内部明确处理 panic，并打出足够可定位的日志，而不是靠调用者猜。

wg.Go(func() {
    defer func() {
        if r := recover(); r != nil {
            logger.Error("worker panic", "job", job.ID, "panic", r)
        }
    }()

    process(job)
})

注意，这不是说每个 goroutine 都要 recover。真正应该做的是：哪些任务允许失败隔离，哪些任务应该直接暴露致命错误，团队要提前定清楚。

适合改造的代码长什么样

我会优先改这几类：

• 循环里固定 Add(1) + go func + defer Done() 的代码。
• 没有 error 返回，只是并发执行后等待完成的任务。
• 历史上出现过 WaitGroup 计数错误、死等、提前 Wait 的模块。
• 新人经常维护、模板代码很多的基础服务。

我不会优先改这几类：

• 已经用 errgroup 管理错误和取消的流程。
• goroutine 启动前后有复杂计数策略的底层库。
• 需要控制并发数量，但当前没有信号量、worker pool 或限流器的代码。
• 为了兼容旧 Go 版本，暂时不能引入 Go 1.25 API 的公共库。

并发数量还是要自己管

WaitGroup.Go 只负责启动和等待，不负责限制并发。很多线上问题不是 WaitGroup 写错，而是一口气拉起几万个 goroutine，把下游数据库、HTTP 接口或者本机内存打满。

如果任务数量不可控，建议配一个信号量：

var wg sync.WaitGroup
sem := make(chan struct{}, 16)

for _, job := range jobs {
    job := job
    sem 

这里 WaitGroup.Go 让生命周期更干净，sem 才是并发上限。两个东西别混着理解。

我会怎么做 code review

如果团队开始用 WaitGroup.Go，我会在 review 里看这几个点。

• 这个 goroutine 是否真的不需要返回 error。
• panic 是否有明确策略，而不是默认“应该不会”。
• 循环变量是否安全，尤其是兼容老版本代码或复制旧习惯时。
• 任务数量是否可能过大，是否需要并发限制。
• 共享数据写入是否有锁、channel 或其他同步手段。
• Wait() 的位置是否能保证调用方拿到完整结果。

这几个问题比“是不是用了新 API”重要得多。新 API 的意义是降低机械错误，不是替你设计并发模型。

迁移建议

我不建议一上来全仓库机械替换。比较稳的做法是先找三类模块：测试代码、内部工具、没有错误返回的批处理逻辑。改完跑一轮测试和压测，再把规则写进团队 Go 代码规范。

如果你们有 lint 或 review checklist，可以加一句：简单等待型 goroutine 优先使用 WaitGroup.Go；需要错误传播和取消时使用 errgroup。这句话比单纯推广 API 有用。

最后说句实在的

WaitGroup.Go 不是革命性功能，但它很适合生产工程。Go 的很多好东西都是这样：看起来小，长期能减少一类无聊但昂贵的错误。

并发代码别追求写得花，先追求边界清楚。能少写模板，就把模板收起来；该处理错误，就别假装 WaitGroup 能替你处理。把这条线画清楚，WaitGroup.Go 就会是一个很好用的小工具。