WaitGroup 必须在启动 goroutine 前调用 Add，且次数与实际 goroutine 数严格一致；goroutine 内须用 defer wg.Done()；必须传指针避免复制；它不解决数据竞争，需额外同步机制。
WaitGroup 必须在启动 goroutine 前调用
这是最常踩的坑：把
放在
里，或者放在 goroutine 启动之后。结果是
可能提前返回，或 panic（如果
在
返回后调用）。
正确做法是：先确定任务数，
在 goroutine 启动前
调用
，且必须保证调用次数与实际启动的 goroutine 数严格一致。
的参数可以是任意正整数，不一定是
；比如批量处理时可一次
不能传负数（会 panic），也不能在
返回后调用（会 panic）
如果任务数动态生成（如从 channel 读取），需用额外变量计数并确保线程安全，或改用其他
同步机制
goroutine 内必须调用
，且仅调用一次
是
的简写，它必须在对应 goroutine 结束前调用。漏调、多调、或在主 goroutine 中误调，都会导致
永久阻塞或 panic。
推荐用
—— 简洁、不易遗漏、自动覆盖所有退出路径（包括 panic）。
立即学习
“
go语言免费学习笔记（深入）
”；
WaitGroup 不能被复制，要传指针
是含 mutex 的结构体，值拷贝会导致未定义行为（常见表现：panic: sync: WaitGroup is reused before previous Wait has returned）。
所有跨 goroutine 共享的场景，都必须传
，而不是
。
函数参数中接收
，而非
闭包内引用外部
变量时，确保该变量本身是地址（即已声明为
或类似）
切忌在循环中对值类型 WaitGroup 做赋值或传参
WaitGroup 不解决数据竞争，只是等待完成
只保证“所有 goroutine 已退出”，**不保证它们操作的数据是安全的**。如果多个 goroutine 并发读写同一变量（如 map、slice、struct 字段），仍需额外同步（
、
或 channel）。
典型反例：用
统计结果，goroutine 直接
—— 这会触发 fatal error: concurrent map writes。
写 map 时加
用
（适合读多写少，但不支持遍历全部 key）
更推荐：每个 goroutine 返回结果，主 goroutine 用 channel 收集后统一写入
WaitGroup 看似简单，但 Add/Wait/Done 的时序和所有权边界稍有偏差就会出问题；尤其要注意“谁负责 Add”“谁负责 Done”“谁持有 wg 指针”这三个责任是否清晰。
Addwg.Add(1)go func() { ... }()Wait()AddWaitAddAdd1wg.Add(len(tasks))Wait()DoneDone()Add(-1)Wait()defer wg.Done()for _, url := range urls {
wg.Add(1)
go func(u string) {
defer wg.Done() // ✅ 安全：无论成功/错误/panic 都执行
resp, err := http.Get(u)
if err != nil {
log.Println(err)
return
}
defer resp.Body.Close()
// ...
}(url)
}sync.WaitGroup*sync.WaitGroupsync.WaitGroupwg *sync.WaitGroupwg sync.WaitGroupwgwg := &sync.WaitGroup{}WaitGroupsync.Mutexsync.Atomicmap[string]intresults[url]++sync.RWMutexsync.Map