Go sync.WaitGroup.Go 怎么替代手写 Add 和 Done：启动时机、panic 语义与收尾检查

项目从 Go 1.24 升到 Go 1.25 后，sync.WaitGroup 多了一个 Go 方法。它把“增加计数、启动 goroutine、退出时调用 Done”这段经常写错的样板收进一个调用里，但不会替你处理错误，也不会把 goroutine 变成可取消任务。

先看旧写法到底容易漏什么

一个批量刷新任务通常是这样写的：

var wg sync.WaitGroup
for _, item := range items {
    wg.Add(1)
    go func(item Item) {
        defer wg.Done()
        refresh(item)
    }(item)
}
wg.Wait()

这段代码的风险不在语法，而在维护时很容易把 Add(1) 放进 goroutine，或者在某个分支提前返回而漏掉 Done。Go 1.25 的 WaitGroup.Go 让“计数和启动”成为一个不可拆开的动作。

最小迁移只需要把任务交给 Go

在 Go 1.25 或更高版本中，等价写法是：

var wg sync.WaitGroup
for _, item := range items {
    item := item
    wg.Go(func() {
        refresh(item)
    })
}
wg.Wait()

循环变量的处理仍然要看项目的 Go 版本和代码形态。显式保留一份 item 局部变量，可以让闭包捕获关系一眼可见，也方便旧版本代码回移植。Go 只负责任务计数和收尾，不会改变 refresh 的并发安全要求。

空计数时，Go 必须先于 Wait

官方文档对启动时机有一个容易被忽略的限制：如果 WaitGroup 当前为空，Go 必须发生在 Wait 之前。实际代码中最稳妥的顺序就是先枚举任务，再等待：

func refreshAll(items []Item) {
    var wg sync.WaitGroup
    for _, item := range items {
        item := item
        wg.Go(func() { refresh(item) })
    }
    wg.Wait()
}

不要让一个“可能还没启动任务”的 goroutine 和主 goroutine 同时决定何时调用 Wait。这样即使没有数据竞争，也会让空 WaitGroup 的启动顺序变得难以复查。

非空 WaitGroup 可以继续添加子任务

当 WaitGroup 已经有未完成任务时，任务函数可以再调用 Go 添加子任务。这适合树状遍历或分层处理，但前提是父任务在返回前把子任务加入计数：

var wg sync.WaitGroup
wg.Go(func() {
    for _, child := range children {
        child := child
        wg.Go(func() { process(child) })
    }
})
wg.Wait()

这里不要把它误读成“可以随时复用”。如果上一组任务的 Wait 已经返回，下一组任务要在上一轮等待结束后重新开始；跨批次交错调用会让生命周期边界变得含糊。

f 不能 panic，错误也不会自动返回

WaitGroup.Go 的函数参数有明确约束：传入的函数不能 panic。它也没有错误返回值，所以不要为了省几行代码，把带错误的工作强行塞进一个只负责等待的 WaitGroup：

type Result struct {
    Item  Item
    Err   error
}

results := make(chan Result, len(items))
var wg sync.WaitGroup
for _, item := range items {
    item := item
    wg.Go(func() {
        value, err := refreshWithError(item)
        results 

这个例子只是展示“显式收集错误”的方向，生产代码还要根据失败是否需要取消其他任务来选择 errgroup 或自定义协调器。若任务可能 panic，应在任务边界明确恢复并转成可观察的错误，而不是依赖 WaitGroup 替你决定故障策略。

版本迁移时要检查四个位置

1. 查找成对出现的 Add(1)、go func 和 defer Done，确认它确实是普通等待场景。
2. 把计数和启动改成 wg.Go(func() { ... })，保留必要的变量副本和锁。
3. 检查任务体是否可能返回错误或 panic；有错误传播要求的代码不要只做机械替换。
4. 用竞态检测和失败用例验证空输入、重复调用、子任务以及上一轮等待后的复用。

go test -race ./...

常见问题

WaitGroup.Go 能替代 errgroup 吗？

不能直接替代。WaitGroup.Go 解决的是 goroutine 计数和等待；errgroup 还提供错误汇总、取消关联等任务编排能力。

任务函数里能调用 Go 吗？

可以，但要保证当前 WaitGroup 仍有未完成任务，并且子任务确实属于当前等待周期。树状任务尤其要写清父子生命周期。

把 panic 转成错误后还需要 WaitGroup 吗？

如果仍然只需要等待全部任务结束，可以继续用；如果还需要首错取消、错误汇总或超时，建议换成具备这些语义的协调方式。

迁移结论：减少样板，不改变并发契约

WaitGroup.Go 适合替换最普通的“启动一批 goroutine，然后等待全部完成”代码。迁移时先确认 Go 版本，再把计数与启动收口，最后检查 panic、错误传播、空计数和跨批次复用边界。它让收尾更不容易漏，但不会替应用设计并发协议。