WaitGroup 必须在启动 goroutine 前调用 Add，否则可能阻塞或 panic；正确做法是先 wg.Add(n)，再启 n 个 goroutine，每个结尾调 wg.Done()；注意闭包陷阱，避免循环变量引用错误。
WaitGroup 必须在启动 goroutine 前完成 Add
常见错误是先 go func() { ... }() 再调用 wg.Add(1)，导致 wg.Wait() 永远阻塞或 panic：「panic: sync: negative WaitGroup counter」。这是因为 Add 和 Done 不是原子配对操作，必须确保计数器在 goroutine 开始执行前已初始化。
正确做法是：先 wg.Add(n)，再启动 n 个 goroutine；每个 goroutine 结束前调用 wg.Done()（或用 defer wg.Done()）。
-
wg.Add()必须在所有go语句之前，或至少在对应 goroutine 执行wg.Done()之前 - 不要在循环里反复
wg.Add(1)后立刻go—— 要么提前算好总数一次性Add，要么确保每次Add紧邻其对应的go - 如果任务数量动态不确定，先遍历一次收集任务，再
Add(len(tasks))，最后统一启动
goroutine 中访问外部变量要小心闭包陷阱
在 for 循环中直接启动 goroutine 并引用循环变量（如 for i := 0; i ），最终可能全部打印 3。这是因为所有 goroutine 共享同一个变量 i 的地址，等它们真正执行时，循环早已结束，i 值为终值。
修复方式是把变量作为参数传入 goroutine 函数，让每个实例拥有独立副本：
立即学习“go语言免费学习笔记（深入）”；
for i := 0; i < 3; i++ {
go func(id int) {
fmt.Println(id)
wg.Done()
}(i) // 注意：i 是立即传值
}或者用局部变量显式捕获：
for i := 0; i < 3; i++ {
i := i // 创建新绑定
go func() {
fmt.Println(i)
wg.Done()
}()
}WaitGroup 不能被复制，必须传指针
sync.WaitGroup 是包含 mutex 和计数器的结构体，禁止值传递。如果函数参数写成 func worker(wg sync.WaitGroup) 或在 goroutine 中传入 wg 值，会导致：fatal error: sync: WaitGroup is reused before previous Wait has returned。
- 所有对
WaitGroup的操作（Add、Done、Wait）都必须作用于同一地址上的实例 - 跨函数调用时，参数类型必须是
*sync.WaitGroup - 启动 goroutine 时，若需在其中调用
Done，也必须传&wg，而不是wg
WaitGroup 不处理 panic，需配合 recover 或日志兜底
WaitGroup 只负责计数和阻塞，不捕获 goroutine 内部 panic。一旦某个 goroutine panic，程序可能崩溃，而 wg.Wait() 还没返回，主流程无法得知哪些任务失败。
实际工程中建议：
- 在每个 goroutine 入口加
defer func(){ if r := recover(); r != nil { log.Printf("goroutine panic: %v", r) } }() - 用带错误通道的模式汇总结果，例如
errCh := make(chan error, n)，每个 goroutine 执行完发errCh ，主协程从通道收错误并判断是否全成功 - 避免在
WaitGroup场景中依赖 panic 做流程控制 —— 它不是错误传播机制
WaitGroup 的核心就三件事：预设数量、各自归零、统一等待。最容易出问题的地方不在语法，而在「谁在什么时候改了计数器」—— 多线程下这点时序稍一错乱，表现就是卡死或 panic，而且难以复现。写的时候多看两眼 Add 和 go 的顺序，比事后 debug 强得多。
