Go sync.WaitGroup Add 放在 goroutine 内为什么有竞态风险

把 wg.Add(1) 写进即将启动的 goroutine，看起来像“任务一开始就登记”，实际上主 goroutine 可能已经先执行到 wg.Wait()。此时计数器还是零，Wait() 会直接返回，调用方误以为所有任务都结束了。修复原则很简单：在创建 goroutine 之前完成正向计数，goroutine 内只负责用 defer wg.Done() 回收自己的计数。

为什么把 Add 写进 goroutine 会让 Wait 失去保护

问题不是 Add 不能并发调用，而是“空计数器上的正向 Add”与 Wait 的先后关系没有被外层代码建立。调度器可以先运行主 goroutine，导致下面的 Wait 在子 goroutine 获得执行机会前就看到零：

var wg sync.WaitGroup

for _, job := range jobs {
	go func(job Job) {
		// 进入工作函数后才加计数，Wait 可能已经先看到零。
		wg.Add(1)
		// 无论正常返回还是提前返回，都要回收本次计数。
		defer wg.Done()
		process(job)
	}(job)
}

// 计数器可能仍是零，Wait 可能过早返回。
wg.Wait()

这类代码有时“运行正常”，只是因为某次调度恰好让子 goroutine 先执行。换一台机器、加一条日志或改变任务量后，主 goroutine 可能更快到达 Wait。因此它不是低概率业务错误，而是生命周期顺序没有写进代码结构。

正确模式：先登记任务，再启动 goroutine

把正向 Add(1) 放在 go 语句前，主 goroutine 先把“将要等待的任务”写进计数器，Wait 就不会在任务尚未登记时提前结束。工作函数只做一件事：完成后调用 Done。

var wg sync.WaitGroup

for _, job := range jobs {
	// 先登记任务，保证后面的 Wait 不会看到空计数器。
	wg.Add(1)
	go func(job Job) {
		// defer 覆盖函数内的多个返回分支，确保计数最终归零。
		defer wg.Done()
		process(job)
	}(job)
}

// 此时所有已创建任务都已经进入计数器。
wg.Wait()

Go 官方文档把这个约束说得很明确：计数器为零时，正向 delta 的 Add 必须发生在 Wait 之前，通常也就意味着它应当写在创建 goroutine 的语句之前。Done 等价于 Add(-1)，它解除的 Wait 返回时，已经建立了完成同步关系。

循环、分批任务和 WaitGroup.Go 怎么选

在循环里使用传统写法时，除了计数顺序，还要确认闭包拿到的是当前任务。把任务作为函数参数传入，比直接捕获循环变量更清楚：

for _, job := range jobs {
	job := job // 明确固定本轮任务，避免闭包误用循环变量。
	wg.Add(1)  // 先增加计数，再创建工作 goroutine。
	go func() {
		defer wg.Done() // 工作函数退出时归还一个计数。
		process(job)    // 只处理本轮已经固定的任务。
	}()
}
wg.Wait() // 等待这一批任务全部归还计数。

如果项目使用 Go 1.25 或更新版本，可以用 WaitGroup.Go：

var wg sync.WaitGroup
for _, job := range jobs {
	job := job // 让闭包绑定当前任务。
	wg.Go(func() {
		process(job) // Go 负责登记任务并在返回时减少计数。
	})
}
wg.Wait() // 等待 Go 加入的任务全部完成。

它适合“启动一个函数并等待它结束”的简单场景，但文档要求传入的函数不能 panic。需要把错误收集到通道、处理重试或控制并发上限时，仍然可以保留显式的 Add/Done，并把这些职责单独写清楚。

分批复用同一个 WaitGroup 时，上一轮 Wait 返回后再开始下一轮的正向 Add。不要让一轮尚未结束的等待与下一轮把计数器重新拉起混在一起。

排查清单：从计数器到生命周期

遇到“偶尔提前返回”时，先不要通过增加 Sleep、打印日志或重复调用 Wait 来碰运气。直接沿着 Add → go → Done → Wait 检查：谁建立计数、谁消费计数、是否存在计数为零时的新任务、是否把同一个 WaitGroup 复制进结构体或函数参数。竞态检测器可以帮助发现共享数据问题，但它不能替代对 WaitGroup 生命周期的人工检查。

相关问题

把 Add 放在 goroutine 外面就一定没有并发问题吗？

它解决的是 WaitGroup 计数与等待的生命周期竞态，不会自动保护 jobs、结果切片或其他共享数据。共享数据仍要用互斥、通道或其他同步方式保护。

Done 能不能写在函数最后一行？

可以，但任何提前返回、错误分支或未来新增的分支都可能漏掉它。入口处使用 defer wg.Done() 更稳妥。

WaitGroup.Go 能不能处理会 panic 的函数？

不应这样用。当前官方文档要求传入函数不能 panic；需要恢复 panic 时，应明确设计恢复边界和错误上报，再决定是否使用显式的 Add/Done。