Go WaitGroup 为什么会出现 Add 与 Wait 并发问题

WaitGroup出现Add与Wait并发问题，常见原因是在新goroutine内部才调用Add：当计数仍是零时，外层Wait可能先返回。对于从零开始的一批任务，应先完成正数Add，再启动需要等待的任务，并为每个任务安排一次Done。不能把规则简化为“Add与Wait任何时候都不能并发”。

官方地址：https://go.dev/

如果日志里先出现“全部完成”，后台任务却还在执行，先检查登记位置。若出现计数为负、重复使用相关panic，则检查Done次数及批次交接。这几种现象可能都涉及WaitGroup，但修复位置不同。

先区分提前返回与计数错误

运行时检查未必在所有错误调度下都报panic；没有panic不能证明登记关系正确。Wait在零计数时直接返回，本身可能完全符合库的行为，只是应用把尚未登记的任务误当成了已登记。

检查Add登记在哪个调用者

下面是错误片段，work代表业务函数：

var wg sync.WaitGroup
// 错误示意：新goroutine不保证先于下方Wait得到调度。
go func() {
    wg.Add(1)
    defer wg.Done()
    work()
}()
wg.Wait()

go语句负责启动任务，并不承诺子任务先执行Add。用Sleep延迟Wait只能改变调度概率，不能建立“任务已经登记”的关系。即使某台机器上重复几次都正常，负载、调度与任务数量变化仍可能暴露问题。

官方规则区分计数是否为零：零计数上的正数Add必须先于Wait；已有正计数时再增加任务可以与等待并存。动态派生子任务时，父任务应在自己仍计入未完成任务期间登记子任务，不能先Done把计数降到零，再发起一批新任务冒充原批次。

把任务登记放在启动之前

以下是可独立保存为main.go的修复示例。任务输入通过参数传给闭包，每项任务对应一个固定结果位置。

package main

import (
    "fmt"
    "sync"
)

func squareAll(values []int) []int {
    results := make([]int, len(values))
    var wg sync.WaitGroup
    for i, value := range values {
        // 当前调用者先登记，再启动任务，避免零计数的Wait提前返回。
        wg.Add(1)
        go func(index, n int) {
            defer wg.Done() // 正常返回和提前return都统一扣减一次。
            // 每个任务只写自己的槽位，不执行并发append。
            results[index] = n * n
        }(i, value)
    }
    wg.Wait()
    // 全部任务完成后，调用者才读取结果。
    return results
}

func main() {
    fmt.Println(squareAll([]int{2, 5, 8}))
}

预期输出为下列内容。这是示例预期，没有声称已在本机执行：

[4 25 64]

本例在循环中的每个go之前Add，Wait位于整个提交循环之后，因此即使早先任务完成很快，也不存在外层Wait先于后续登记启动的问题。对固定任务数量，也可以在循环前一次Add(len(values))，但只有确保全部已登记任务都有执行或撤销计数的路径时才合适。

若任务提交给可能拒绝请求的执行器，不能只Add却在提交失败时忘记恢复计数。先定义提交成功与失败分别由谁Done，再写代码；不要把同一个Done同时交给调用者和任务。

确认同一批任务与结果归属

WaitGroup只管理完成计数，不保护共享map、切片append和业务对象。示例把结果切片长度固定，每个任务只写一个不同槽位，并在Wait之后读取。若改成所有任务同时append同一切片，仍需额外同步。

排查时确认所有参与者操作的是同一个WaitGroup。使用后不要按值复制它；辅助函数需要接收时，传指针。结构体按值传参、值接收者方法和复制包含WaitGroup的对象，都可能把计数与等待者分到不同副本。

WaitGroup不收集错误，也不取消其他任务。如果一个任务失败，仍应完成自己的计数归还；是否取消同批其他任务、如何保存错误，需要另外安排Context或结果通道。不要在子任务中调用os.Exit来替代错误传播。

按批次检查复用和退出路径

独立批次复用时，新的Add必须在前一批所有Wait调用返回后进行。仅看到最后一个工作任务调用Done，不等于所有等待者已经退出。若批次可以重叠，给每一批使用自己的局部WaitGroup往往更容易表达归属。

项目中可按以下位置逐项检查：零计数时谁负责登记；每个Add对应哪条完成路径；提前返回是否仍调用Done；是否发生值复制；新的批次是否越过旧批等待边界。这些位置比给Wait加一个任意延时更有解释力。

# 在现有模块中对相关包做并发诊断；测试通过仍需满足登记规则。
go test -race ./...
# 静态分析可辅助发现部分WaitGroup误用，诊断能力随工具链变化。
go vet ./...

上面命令供读者在自己的项目中使用，本文没有运行代码或据此宣称项目通过检查。竞态检测依赖实际执行路径，也不能替代任务登记的逻辑约束。

已有任务还没结束时，能再Add吗？

可以在计数为正时登记额外任务，但必须保证登记者尚属于有效批次，不能让计数先归零再无序开启新批。

WaitGroup.Go能减少这类错误吗？

Go 1.25新增的WaitGroup.Go将启动与登记封装在一起，可减少手写Add与Done配对。空组上首次Go仍须先于Wait，传入函数不得panic，使用时也不要再手动Done。

Wait能设置超时吗？

Wait方法本身没有超时参数。即使调用者停止等待，工作任务也不会自动停止，任务取消与退出协议仍要单独设计。

修复重点是任务登记、完成和等待使用同一个清楚的批次：先让任务成为等待对象，再启动它；每项任务只归还一次计数。

官方资料：WaitGroup.Add；WaitGroup.Go。