WaitGroup计数提前归零怎么办

如果 WaitGroup.Wait() 很快返回，但后台任务明显还没有结束，先别把它和“负计数 panic”混为一谈。前一种情况通常是等待时计数仍为零：Add(1) 放在了新 goroutine 内，Wait 先一步观察到零值并直接返回。后一种情况则是 Done 调用次数超过了注册数量，计数减到了负数。

最稳妥的修复顺序是：在创建 goroutine 之前完成全部 Add，在任务入口用 defer wg.Done() 保证恰好结束一次；如果使用 Go 1.25.0 及以上，再考虑用 WaitGroup.Go 把启动和计数绑定起来。

本文的示意图只表达代码实体之间的静态关系，不是终端截图或实际运行结果。官方资料可参考 https://pkg.go.dev/sync。

先还原 Wait 为什么会提前返回

WaitGroup 等待的是任务计数，不是“已经创建了多少个 goroutine”。当计数为零时，Wait 没有需要等待的对象；如果此时另一个 goroutine 还没来得及执行 Add(1)，主协程就会继续向下运行。

var wg sync.WaitGroup

for _, job := range jobs {
	go func(job Job) {
		// 错误示例：Add 可能晚于 Wait，主协程会先看到零值。
		wg.Add(1)
		defer wg.Done()
		process(job)
	}(job)
}

// 这里可能在任何一个 goroutine 执行 Add 前就返回。
wg.Wait()

这段代码的隐患不是 goroutine 一定启动得慢，而是 Add 与 Wait 之间没有建立可靠的注册关系。调度顺序一变，表现就可能从“偶尔提前返回”变成“看起来一直正常”。

把 Add 放在启动任务之前

修复时先登记任务，再创建 goroutine。这样主协程执行到 Wait 时，计数已经至少大于零；任务结束时再由同一个任务调用一次 Done 抵消这次登记。

var wg sync.WaitGroup

for _, job := range jobs {
	// 先注册任务，避免 Wait 在计数为零时直接返回。
	wg.Add(1)
	go func(job Job) {
		// defer 覆盖提前 return 和处理失败的分支。
		defer wg.Done()
		process(job)
	}(job)
}

// 所有任务都已注册，等待计数降回零。
wg.Wait()

如果任务数量在启动前就能确定，也可以先调用一次 wg.Add(len(jobs))，再在每个任务中调用一次 Done。无论选哪种写法，注册数量和结束数量都必须成对。

使用 Go 1.25.0 及以上时，还可以把这组约束交给 WaitGroup.Go：

var wg sync.WaitGroup

for _, job := range jobs {
	// Go 负责注册任务、启动 goroutine，并在函数返回时减少计数。
	wg.Go(func() {
		process(job)
	})
}

// 任务全部返回后，Wait 才会结束阻塞。
wg.Wait()

沿着三条边界排查计数失真

若已经把 Add 移到 go 语句之前，仍要检查下面三类边界。

还要注意不要复制已经使用过的 WaitGroup，也不要让一个任务在多个分支中重复执行 Done。如果任务可能提前返回、遇到错误或被取消，把 Done 放进入口处的 defer 通常更容易保持对称。

用最小证据确认修复没有漏项

排查时不要只看最终输出，建议给每个任务带上标识，记录“注册、开始、结束”三个事件，重点观察是否有任务开始前没有注册，或同一任务出现两次结束。日志只用于核对生命周期，不应拿来代替同步本身。

# 先做静态检查，捕获部分并发 API 的可疑用法。
go vet ./...

# 再运行竞态检测；它能发现数据竞争，但不能替代 Add/Done 数量核对。
go test -race ./...

最后按这份清单收口：Add 是否发生在 Wait 之前；每个已注册任务是否只调用一次 Done；循环中的错误分支是否仍然结束计数；下一轮是否等上一轮 Wait 返回；项目是否已经满足 WaitGroup.Go 的 Go 版本要求。

相关问题

Wait 提前返回一定是 Add 放错位置吗？ 不一定，也可能是任务数量漏注册、某个循环分支绕过了 Add，或等待的不是实际启动任务使用的那个 WaitGroup。先按任务 ID 对照注册和结束事件。

计数归零后还能继续 Add 吗？ 可以复用，但前一组任务的 Wait 必须已经返回；当计数为零时，新的正增量不能与正在进行的等待并发发生。

WaitGroup.Go 能解决所有并发问题吗？ 不能。它主要收拢任务启动和计数管理，任务内部的数据竞争、共享状态保护和错误传递仍需单独设计。