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 done\n", id)
}(i)
}
wg.Wait() // 阻塞直到所有 Done 被调用
Done 和 Add(-1) 的行为完全等价，但别混用
Done() 本质就是 Add(-1)，二者可互换。但混用会降低可读性，且容易漏掉 Done ——尤其在有多个 return 分支的函数中。
建议统一用 defer wg.Done()，确保无论从哪个出口退出，计数都能减少。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 如果函数里有多个 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。
