17370845950

WaitGroup 必须在启动 goroutine 前调用 Add，且次数与实际 goroutine 数严格一致；goroutine 内须用 defer wg.Done()；必须传指针避免复制；它不解决数据竞争，需额外同步机制。

WaitGroup 必须在启动 goroutine 前调用 Add

这是最常踩的坑：把 wg.Add(1) 放在 go func() { ... }() 里，或者放在 goroutine 启动之后。结果是 Wait() 可能提前返回，或 panic（如果 Add 在 Wait 返回后调用）。

正确做法是：先确定任务数，在 goroutine 启动前 调用 Add，且必须保证调用次数与实际启动的 goroutine 数严格一致。

• Add 的参数可以是任意正整数，不一定是 1；比如批量处理时可一次 wg.Add(len(tasks))
• 不能传负数（会 panic），也不能在 Wait() 返回后调用（会 panic）
• 如果任务数动态生成（如从 channel 读取），需用额外变量计数并确保线程安全，或改用其他同步机制

goroutine 内必须调用 Done，且仅调用一次

Done() 是 Add(-1) 的简写，它必须在对应 goroutine 结束前调用。漏调、多调、或在主 goroutine 中误调，都会导致 Wait() 永久阻塞或 panic。

推荐用 defer wg.Done() —— 简洁、不易遗漏、自动覆盖所有退出路径（包括 panic）。

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)
}

WaitGroup 不能被复制，要传指针

sync.WaitGroup 是含 mutex 的结构体，值拷贝会导致未定义行为（常见表现：panic: sync: WaitGroup is reused before previous Wait has returned）。

所有跨 goroutine 共享的场景，都必须传 *sync.WaitGroup，而不是 sync.WaitGroup。

• 函数参数中接收 wg *sync.WaitGroup，而非 wg sync.WaitGroup
• 闭包内引用外部 wg 变量时，确保该变量本身是地址（即已声明为 wg := &sync.WaitGroup{} 或类似）
• 切忌在循环中对值类型 WaitGroup 做赋值或传参

WaitGroup 不解决数据竞争，只是等待完成

WaitGroup 只保证“所有 goroutine 已退出”，**不保证它们操作的数据是安全的**。如果多个 goroutine 并发读写同一变量（如 map、slice、struct 字段），仍需额外同步（sync.Mutex、sync.Atomic 或 channel）。

典型反例：用 map[string]int 统计结果，goroutine 直接 results[url]++ —— 这会触发 fatal error: concurrent map writes。

• 写 map 时加 sync.RWMutex
• 用 sync.Map（适合读多写少，但不支持遍历全部 key）
• 更推荐：每个 goroutine 返回结果，主 goroutine 用 channel 收集后统一写入

WaitGroup 看似简单，但 Add/Wait/Done 的时序和所有权边界稍有偏差就会出问题；尤其要注意“谁负责 Add”“谁负责 Done”“谁持有 wg 指针”这三个责任是否清晰。