Golang如何使用WaitGroup_Golang并发任务等待机制说明

WaitGroup 用于主 goroutine 等待其他 goroutine 完成，Add 必须在 go 语句前调用且与启动 goroutine 数量匹配，否则导致提前返回或 panic；计数器初始为 0，Done 等价于 Add(-1)。

WaitGroup 是 Go 标准库 sync 包里最常用、也最容易用错的并发同步工具之一。它不负责传递数据，只解决「主 goroutine 等待其他 goroutine 执行完毕」这个单一问题——但一旦 Add 和 Done 调用不匹配，就会 panic 或死锁。

WaitGroup 的 Add 必须在 goroutine 启动前调用

这是最常踩的坑：把 Add(1) 放在 go func() 内部，导致主 goroutine 调用 Wait() 时计数器仍是 0，直接返回，后续 goroutine 还没执行完程序就退出了。

正确做法是：

• Add 必须在 go 语句之前调用，确保计数器已更新
• 如果启动 N 个 goroutine，就要提前 Add(N)；不能靠循环里每个 goroutine 自己 Add(1)
• 计数器初始值为 0，Add 可传负数（但通常只用 Done() 来减）

示例：

立即学习“go语言免费学习笔记（深入）”；

var wg sync.WaitGroup for i := 0; i < 3; i++ {     wg.Add(1) // ✅ 在 go 前     go func(id int) {         defer wg.Done() // ✅ 或显式调用 wg.Done()         fmt.Printf("task %d donen", id)     }(i) } wg.Wait() // 阻塞直到所有 Done 被调用

Done 和 Add(-1) 的行为完全等价，但别混用

Done() 本质就是 Add(-1)，二者可互换。但混用会降低可读性，且容易漏掉 Done ——尤其在有多个 return 分支的函数中。

建议统一用 defer wg.Done()，确保无论从哪个出口退出，计数都能减少。

• 如果函数里有多个 Error return，不用每个都写 wg.Done()
• 避免在循环体中直接调用 Done() 而忘记 defer，容易因 panic 跳过
• 不要在同一个 WaitGroup 上重复调用 Done() 超过 Add 总数，否则 panic: "sync: negative WaitGroup counter"

WaitGroup 不能被复制，必须传指针

sync.WaitGroup 是包含 mutex 和原子计数器的结构体，按值传递会复制一份独立状态，导致主 goroutine 等的不是同一组 goroutine。

典型错误写法：

func spawn(wg sync.WaitGroup) { // ❌ 值传递，wg 是副本     wg.Add(1)     go func() { wg.Done() }() } // 调用后 wg.Wait() 永远阻塞

正确方式只有两种：

• 定义为包级变量（不推荐，破坏封装）
• 函数参数用 *sync.WaitGroup（✅ 推荐）

例如：func worker(wg *sync.WaitGroup, job String)，调用时传 &wg。

WaitGroup 不适合做“条件等待”或“带超时的等待”

WaitGroup.Wait() 是纯阻塞调用，没有上下文支持，也没有超时机制。如果你需要：

• 等待最多 5 秒 → 得配合 time.AfterFunc 或 select + time.After
• 等待某个条件成立（如 channel 关闭、变量变化）→ 应该用 sync.Cond 或 channel
• 取消正在等待的 Wait → WaitGroup 本身不支持，得结合 context.Context 自行控制 goroutine 生命周期

换句话说：WaitGroup 只回答一个问题——“那些我 Add 过的 goroutine，都 Done 了吗？” 它不管它们干了什么、结果如何、有没有卡住。

真正难的不是调用 Wait()，而是确保每次 Add 都有对应且仅一次的 Done，尤其是在错误路径、recover、或者提前 return 的场景下。漏一个，程序就 hang；多一个，直接 panic。