Go sync.WaitGroup Done 少调用一次为什么会一直等待

Go 里 sync.WaitGroup 的 Wait() 一直等待，最常见的原因不是 goroutine “跑得慢”，而是任务计数没有回到 0。每调用一次 Add(1)，就必须让对应任务在所有返回路径上调用一次 Done()；少调用一次，Wait() 就没有释放条件。

官方文档：https://pkg.go.dev/sync。下面用一个小型批处理器说明这个问题。

WaitGroup 的计数器为什么会一直大于零

WaitGroup 可以看作一个任务计数器：Add(1) 增加一个待完成任务，Done() 减少一个任务，Wait() 只在计数器归零后返回。它并不知道某个 goroutine 已经从函数末尾离开，因此 goroutine 返回不等于自动完成。

例如要处理 3 个任务，先执行 wg.Add(3)，理论上必须出现 3 次 Done()。如果其中一个任务走了提前返回分支，计数就会停在 1，主 goroutine 会卡在 wg.Wait()。相反，Done 多调用一次会让计数变成负数并触发 panic。

用一个批处理小项目复现漏掉 Done

下面的代码模拟并发处理任务。问题藏在 Skip 分支：任务被跳过时直接返回，但没有完成计数。

type Task struct {
    ID   int
    Skip bool
}

func runBatch(tasks []Task) {
    var wg sync.WaitGroup
    wg.Add(len(tasks)) // 中文注释：先登记将要等待的任务总数

    for _, task := range tasks {
        go func(t Task) {
            if t.Skip {
                return // 中文注释：这里漏了 Done，计数器会永久多 1
            }
            process(t)
            wg.Done() // 中文注释：只有正常路径才会减少计数
        }(task)
    }

    wg.Wait() // 中文注释：只有所有任务都完成，主流程才继续
}

修复时不要在每个分支手写一份 Done()。把它放到 goroutine 函数入口后的 defer，让函数无论从哪里返回都只承担一次完成责任：

func runBatch(tasks []Task) {
    var wg sync.WaitGroup
    wg.Add(len(tasks)) // 中文注释：Add 的数量必须与实际启动的任务一一对应

    for _, task := range tasks {
        go func(t Task) {
            defer wg.Done() // 中文注释：覆盖正常返回、跳过和错误返回
            if t.Skip {
                return // 中文注释：提前退出也会先执行 defer
            }
            process(t)
        }(task)
    }

    wg.Wait() // 中文注释：等待计数器归零，不负责修正错误计数
}

用 defer 让每条返回路径都完成 Done

defer wg.Done() 最适合放在 goroutine 函数的第一段可执行逻辑附近，而不是放在业务函数最后。这样新增校验、错误处理或取消分支时，不容易忘记同步清理。

还要注意两个边界。第一，Add 必须发生在对应 goroutine 启动前，尤其是计数器原本为 0 时，不能让 Wait 与正数 Add 产生不明确的并发关系。第二，同一个任务不要同时使用 defer 和手写 Done，否则会多减一次。

如果项目工具链支持 WaitGroup.Go，也可以让标准库替你绑定“启动任务”和“完成任务”这两个动作：

for _, task := range tasks {
    task := task // 中文注释：让闭包持有当前任务值
    wg.Go(func() {
        process(task) // 中文注释：函数返回时由 WaitGroup 结束该任务
    })
}
wg.Wait() // 中文注释：等待所有 Go 注册的任务完成

若仍使用传统写法，Add、go 和 defer Done 放在同一小段代码里，审查时最容易对照。

排查 Wait 一直等待的检查清单

1. 数 Add：确认它登记的是任务数，而不是循环次数之外的重复数量。
2. 找所有返回：包括参数校验失败、超时、取消、空结果和错误处理分支。
3. 查 Done 数：一个任务只能有一个完成责任，避免 defer 与显式调用叠加。
4. 看 goroutine 是否真的退出：如果 Done 已配对仍不返回，继续排查阻塞的 channel、锁或 IO。
5. 不要把 time.Sleep 当修复；它只能改变调度时机，不能让计数器归零。

相关问题

Done 少调用一次一定会 panic 吗？

不一定。少调用通常表现为 Wait() 一直阻塞；只有 Done 多调用或计数被减到负数时，才会出现 negative WaitGroup counter panic。

可以在 goroutine 里面调用 Add 吗？

如果 WaitGroup 当前计数为 0，不应把正数 Add 和 Wait 竞争；更稳妥的做法是在启动 goroutine 前登记任务。已有正数任务时，嵌套任务也要明确管理生命周期。

为什么用了 defer Done 仍然卡住？

先确认 defer 所在的函数确实被启动，并且该 goroutine 没有卡在 channel、锁或外部 IO；WaitGroup 只负责计数，不会替你解除其他阻塞。