并发计数

“并发计数”这个问题的关键不在于 Add 是否能被 goroutine 调用，而在于 Wait 是否可能在这次正向计数发生前就观察到零。把 wg.Add(1) 写进刚启动的 goroutine，会让启动动作和计数动作之间出现竞态窗口：主 goroutine 可能先执行 Wait，直接返回，调用方随后才开始真正的工作。

稳妥规则是：当 WaitGroup 当前计数为零时，所有正数 Add 都要发生在 Wait 之前，通常也就是写在 go 语句之前。goroutine 内只负责 defer wg.Done()。

风险来自“启动”和“计数”没有绑定

下面的写法看起来像是“每个任务自己登记一次”，但登记动作并不发生在 go 语句执行的同一时刻：

var wg sync.WaitGroup

for _, job := range jobs {
	job := job
	go func() {
		// 这里的 Add 可能晚于主 goroutine 调用 Wait。
		wg.Add(1)
		defer wg.Done()
		process(job)
	}()
}

// 如果计数器仍是 0，Wait 可能立即返回。
wg.Wait()

这里并不是每次都会失败，正因为调度结果不固定，问题才容易被误认为“偶发”。当某个 goroutine 恰好先运行，结果可能正常；当主 goroutine 先走到 Wait，它看到的是尚未登记的任务集合。图1把这几个静态对象放在同一张结构说明图中，重点看“任务启动”和“计数器”的边界，而不是把图片当作运行截图。

把计数放在 go 之前，形成对称收口

最小修复是先登记、再启动；任务完成时用 Done 抵消一次计数。defer 应放在 goroutine 入口附近，这样业务函数提前返回时也不会漏掉收口：

var wg sync.WaitGroup

for _, job := range jobs {
	job := job // 每个闭包保留自己的任务值。
	wg.Add(1) // 先把任务纳入 Wait 的计数范围。
	go func() {
		defer wg.Done() // 无论中途 return，都要归还一个计数。
		process(job)
	}()
}

wg.Wait() // 此时正数 Add 已经全部完成。

这个顺序同时解决两个问题：第一，Wait 不会在任务登记前看到零；第二，每个已登记任务都有明确的 Done。如果 process 内部还会派生新的 goroutine，不要把“谁负责登记、谁负责收口”留给约定俗成的猜测，应该让拥有任务生命周期的那一层明确承担计数。

几个容易混淆的边界

正数 Add 不是任何时候都不能并发调用。官方规则的重点是计数器为零时的正向 Add 必须先于 Wait；当计数器已经大于零时，后续正向 Add 可以在任务执行期间发生。因此，批量启动任务时仍建议统一先 Add 再 go，让任务集合一眼可见。

Done 多一次会触发负计数 panic。每次 Add(1) 必须恰好对应一次 Done()。不要在公共收尾函数和调用方各自 defer 一次，也不要把同一个 WaitGroup 复制后分别使用。

循环变量要单独确认。把 job := job 放在循环体内，或把任务作为匿名函数参数传入，能让示例意图更清晰；这和 Add 的时序是两个独立问题，修好计数不代表闭包读取任务值就一定符合预期。

复用要等上一次 Wait 返回。如果把一个 WaitGroup 用于多轮互相独立的任务，下一轮的正数 Add 应在上一轮 Wait 返回之后开始。不要在上一轮仍可能收尾时混入下一轮的计数。

什么时候可以用 WaitGroup.Go

较新的 Go 标准库文档提供了 WaitGroup.Go：它把“启动 goroutine”和“增加任务计数”收拢到一个方法里，任务函数返回时自动减少计数。适合直接表达“把这个函数作为一个待等待任务运行”的场景：

var wg sync.WaitGroup

for _, job := range jobs {
	job := job
	wg.Go(func() {
		// Go 负责登记与收口，函数体只处理任务。
		process(job)
	})
}

wg.Wait() // 等待 Go 登记的全部任务结束。

如果项目需要兼容没有该方法的 Go 版本，继续使用“Add 在 go 之前、Done 用 defer”的写法即可。无论选择哪种形式，都要把注意力放在任务集合的边界：谁启动任务，谁登记任务，谁保证任务最终完成。

速查：看到哪种写法该怎么判断

相关问题

问：Add 放在 go 之后一定错吗？答：不应把它作为通用写法。当 WaitGroup 已经有正计数、且当前 Wait 不会与这次 Add 形成空计数竞态时，规则允许更灵活的安排；但批量启动的常见场景没有必要承担这个时序成本。

问：为什么推荐 defer Done？答：它把收口绑定到函数退出路径，能覆盖正常返回和多个分支；如果任务可能 panic，还应根据项目的错误处理策略决定是否恢复，不能把 WaitGroup 当作 panic 处理器。