当前位置：首页 > 文章列表 > Golang > Go问答 > Go sync.WaitGroup Done 少调用一次为什么会一直等待

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

来源：17golang原创 2026-09-11 09:50:35 0浏览收藏

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

要点速览

Done() 等价于 Add(-1)，它不会因为 goroutine 自然返回而自动执行。
把 defer wg.Done() 放在 goroutine 函数入口，能覆盖正常返回、错误返回和提前退出。
先核对 Add 的任务数，再逐个检查分支、循环和闭包；不要用超时掩盖计数配对错误。

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

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

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

Go sync.WaitGroup 任务计数边界与三个 worker 的 Done 配对关系静态技术框图 — 图1：把任务计数、worker 和 Done 放在同一张关系图里，漏掉任意一个 Done 都会让 Wait 继续等待。

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

现象	通常对应的计数问题	先检查哪里
Wait 一直不返回	Done 少调用或某个任务没有退出	每个 return、错误分支和取消分支
negative WaitGroup counter	Done 多调用，或 Add 数量算少	回调、重试和重复 defer
偶发等待	分支与调度组合后才触发漏 Done	循环闭包、早退和共享计数器

用一个批处理小项目复现漏掉 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 函数的第一段可执行逻辑附近，而不是放在业务函数最后。这样新增校验、错误处理或取消分支时，不容易忘记同步清理。

Go worker 函数中 defer Done 覆盖正常返回错误返回和提前退出的静态关系框图 — 图2：defer Done 位于 worker 函数入口后，正常返回、错误返回和提前退出都共享同一个完成责任。

还要注意两个边界。第一，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 放在同一小段代码里，审查时最容易对照。