WaitGroup.Add()必须在goroutine启动前调用，否则计数器为负导致panic；复用需新建实例或Go1.20+用Add(0)清零；Done()须defer确保执行；结果传递应使用channel而非共享变量。
WaitGroup.Add() 调用时机错误导致 panic
最常见的问题是 Add() 在 goroutine 启动后才调用，或在循环中漏掉调用。Go 运行时检测到 Wait() 时计数为负，会直接 panic：panic: sync: negative WaitGroup counter。
根本原因：WaitGroup 内部计数器不是原子地“预分配”，而是靠你手动配平 Add(n) 和 Done()。它不校验调用顺序，只做整数加减 —— 所以 Add(-1) 或先 Done() 后 Add() 都会崩。
- ✅ 正确做法：必须在启动 goroutine 之前 调用
Add(1) - ❌ 错误写法：
go func() { wg.Done() // ... work }() wg.Add(1) // 晚了！wg 可能已 Wait() 或 Done() 导致负计数 - ⚠️ 循环中易错：
for i := range tasks { go f(&wg, i); wg.Add(1) }是对的；但若把wg.Add(1)写在 goroutine 内部、且没加锁，就可能漏加或多加
WaitGroup 复用未重置引发阻塞
WaitGroup 不是线程安全的“可重入”对象 —— 它没有 Reset() 方法（Go 1.20 前），重复使用前必须确保前一次 Wait() 已返回且所有 Done() 已执行完毕。否则新一批 goroutine 的 Done() 会作用在旧计数上，造成 Wait() 永远不返回。
典型场景：HTTP handler 中复用局部 WaitGroup 变量，或作为 struct 字段反复调用。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- ✅ 安全做法：每次需要等待新一批任务时，声明新的
sync.WaitGroup实例 - ✅ Go 1.20+ 可用
wg.Add(0)清零（仅当计数为 0 时有效），但语义不清晰，不如新建 - ❌ 危险模式：
var wg sync.WaitGroup for range requests { wg.Add(len(tasks)) for _, t := range tasks { go func() { defer wg.Done(); do(t) }() } wg.Wait() // 第二轮开始前没重置 wg → panic 或死锁 }
goroutine 泄漏：Done() 忘记调用或 panic 跳过
如果某个 goroutine 因 panic、return 提前退出，或逻辑分支遗漏 defer wg.Done()，Wait() 就永远卡住 —— 表现为程序 hang 住、CPU 降为 0、无错误输出。
这比 panic 更难排查，因为没有崩溃信号，只有超时或监控告警才暴露问题。
- ✅ 强制习惯：所有
go启动的函数入口第一行写defer wg.Done() - ✅ 若需条件执行
Done()，务必包在defer+if里，避免裸调用 - ⚠️ 注意 recover 场景：
go func() { defer wg.Done() defer func() { if r := recover(); r != nil { log.Println("panic:", r) } }() riskyOp() // panic 时 wg.Done() 仍会执行 }()
WaitGroup 不能替代 channel 传递结果
新手常误以为 WaitGroup 能“收集返回值”，于是用闭包变量共享结果：
var result string
wg.Add(1)
go func() {
defer wg.Done()
result = heavyCompute()
}()
wg.Wait()
fmt.Println(result) // 竞态！result 可能未赋值或被覆盖这是数据竞争（data race），go run -race 会报错。WaitGroup 只管“是否结束”，不管“结果如何”。
- ✅ 正确方式：用 channel 收集结果，或用 mutex + slice 安全写入
- ✅ 简单场景：直接
return结果并用 channel 接收，例如ch - ⚠️ 注意：多个 goroutine 写同一变量且无同步机制，无论 WaitGroup 是否 Wait，都是竞态
WaitGroup 的设计非常轻量，正因如此，它把责任完全交给了使用者：计数配平、生命周期管理、结果同步都得自己兜底。最容易被忽略的，其实是“它根本不关心你在 goroutine 里干了什么” —— Done 调用与否、何时调用、是否 panic，全靠你代码写对。
