Go sync.WaitGroup.Go 如何组织任务收尾：Add 竞态与错误传播边界

批处理服务里最难受的一类问题，不是任务没启动，而是主流程偶尔先打印“全部完成”，随后日志里才出现某个子任务的结果。旧写法通常把 wg.Add(1)、go func 和 wg.Done() 分散在几行里，启动时机一变，计数就可能和任务生命周期脱节。Go 1.25 的 sync.WaitGroup.Go 把这段样板收拢了，但它解决的是“计数与收尾绑定”，不是错误收集器。

把独立任务交给 wg.Go，再由 wg.Wait 等待；错误需要显式写入结果通道或结果切片，任务函数不能 panic。若仍需要返回错误，单独设计错误传播路径。

一次提前收尾，暴露了 Add 与任务启动的竞态

现场代码负责并发处理三份文件。它在循环中调用 go func，同时把 wg.Add(1)（也就是 WaitGroup.Add）放到了 goroutine 内部。主 goroutine 很快走到 wg.Wait()，这时计数器可能仍然是 0，于是等待立即返回，任务结果会在批次已经收尾后才出现。问题不一定每次出现，机器负载越高越容易被放大。

var wg sync.WaitGroup
for _, file := range files {
    go func(file string) {
        wg.Add(1)
        defer wg.Done()
        process(file)
    }(file)
}
wg.Wait()

这里的关键不是把 Wait 换成更长的等待，而是让“任务登记”发生在启动动作之前。计数器代表的是已经交给并发流程的任务，不是未来某个 goroutine 可能补上的数字。

用 WaitGroup.Go 把启动、计数和收尾放回一条链

如果任务只需要被等待，不需要把错误直接从 WaitGroup 返回，改成 wg.Go 会更直白。调用点登记任务，函数返回时由标准库完成计数减少，正文逻辑里不再手写 Add 与 Done 的配对。

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

这里的 file := file 是闭包取值的明确写法，避免读者把任务计数修好后，又被循环变量捕获问题干扰。官方文档还说明：当 WaitGroup 已经非空时，由任务继续调用 Go 是允许的；但一组任务已经结束并准备复用时，要等前一次 Wait 返回后再开始下一组。

错误为什么不会自动从 WaitGroup 里冒出来

WaitGroup 只知道“还有几个任务没结束”，不知道任务业务结果。下面的示例把错误写入带缓冲的通道，主流程先等待，再关闭通道并读取结果。通道容量等于任务数量，确保任务不会因为主流程正在等待而卡在发送错误这一步。

errCh := make(chan error, len(files))
var wg sync.WaitGroup

for _, file := range files {
    file := file
    wg.Go(func() {
        if err := process(file); err != nil {
            errCh 

如果业务只允许返回第一个错误，可以给通道容量设为 1，并在任务函数里配合取消信号；如果要收集全部文件失败原因，就保留每个错误并在等待后统一汇总。两种方案都需要你定义“失败后其他任务是否继续”，WaitGroup.Go 不会替你做这个决策。

三个边界要在代码评审里单独验收

尤其要注意“把 wg.Go 当作 errgroup.Group.Go”这个误解。前者的返回值是空的，只提供任务计数与等待关系；后者才是以错误为中心的并发抽象。项目若需要首错取消、错误聚合和上下文联动，应直接选用与这些要求匹配的实现，不要在 WaitGroup 上猜一个不存在的语义。

运行检查：让结果和收尾同时出现

用 Go 1.25 或更新工具链编译示例，检查点不是某个固定耗时，而是日志顺序和错误数量：所有任务的处理日志先出现，wg.Wait 后的“批次收尾”日志最后出现；故意让一个 process(file) 返回错误时，errCh 能读到它，其他任务是否继续则符合你的业务选择。

fmt.Println("批次收尾")

如果编译器提示 WaitGroup 没有 Go 方法，先检查实际 go version 和模块的 go 行，而不是复制一份自定义包装器。官方同步包文档把该方法标为 Go 1.25.0 新增。

相关问题

WaitGroup.Go 能不能直接返回 error？

不能。它的签名是 Go(f func())，错误必须通过通道、共享结果或其他并发抽象传出去。

任务函数 panic 时 WaitGroup.Go 会帮忙恢复吗？

不会。官方约束是任务函数不能 panic，需要恢复时应在函数内部设计明确的错误状态。

WaitGroup.Go 可以在任务内部继续调用吗？

当 WaitGroup 当前非空时可以；如果它已为空并准备开始一组新任务，应确保调用 Go 发生在对应 Wait 之前，并按轮次管理复用边界。

总结

WaitGroup.Go 最有价值的地方，是让任务登记和任务收尾贴在同一个调用点上，减少 Add 放错位置、Done 漏写这类生命周期错误。它仍然只是等待计数器：错误、取消和 panic 都要由业务代码明确处理。评审并发代码时，先核对任务是否在 Wait 前登记，再核对错误是否有真实出口，通常比盯着 goroutine 数量更快定位问题。