sync.WaitGroup 是等待多个 goroutine 完成的最常用且可靠方式，需在启动前调用 Add()、goroutine 内用 defer Done()、主协程调用 Wait() 阻塞等待。
用 sync.WaitGroup 等待多个 goroutine 完成是最常用且可靠的方式
Go 没有内置的“等待所有 goroutine 结束”语法，sync.WaitGroup 是标准库提供的轻量级同步原语，专为这类场景设计。它通过计数器 + 阻塞等待实现协作式同步，不依赖 channel 或 sleep 轮询。
关键点在于：必须在启动 goroutine 之前调用 Add()，且每个 goroutine 内部必须调用 Done()；Wait() 会阻塞直到计数归零。
-
Add(1)必须在 goroutine 启动前调用，否则可能因竞态导致计数未生效 - 不要在 goroutine 外部调用
Done()，也不要用defer Done()在非 goroutine 函数中——Done()只应在对应 goroutine 内执行 - 计数器不可为负，多次调用
Done()会 panic，务必确保每个Add()都有且仅有一个匹配的Done()
package mainimport ( "fmt" "sync" "time" )
func main() { var wg sync.WaitGroup urls := []string{"https://www.php.cn/link/e75a2d435455f0626ccf0af67216e76f", "https://www.php.cn/link/88b3febc5798a734026c82c1012408f5", "https://www.php.cn/link/6fe0fa22eca4dea0f85b883b75c76a34"}
for _, url := range urls { wg.Add(1) // 注意：这里在 goroutine 外、启动前调用 go func(u string) { defer wg.Done() // 在 goroutine 内调用 fmt.Printf("Fetching %s...\n", u) time.Sleep(500 * time.Millisecond) fmt.Printf("Done: %s\n", u) }(url) } wg.Wait() // 主 goroutine 阻塞等待全部完成 fmt.Println("All done.")}
为什么不用
channel配合for range等待？用 channel 收集完成信号（如
done := make(chan struct{}, N)）也能工作，但属于“手动模拟 WaitGroup”，增加了复杂度和出错风险。常见问题包括：
- 缓冲区大小设错（比如
make(chan struct{}, 2)却发 3 个信号 → 第三个写操作阻塞） - 忘记关闭 channel，导致
for range永远不退出 - goroutine panic 后未发送信号，主 goroutine 永久等待（
WaitGroup同样会卡住，但至少不会因 channel 操作 panic） - 无法复用：每次都要新建 channel 和循环逻辑，而
sync.WaitGroup可重置（WaitGroup{}重新赋值）或直接新建
除非你同时需要返回结果或错误（这时用带类型的 channel 更自然），否则纯等待完成，sync.WaitGroup 更简洁、安全、符合 Go 的惯用法。
WaitGroup 的底层行为与注意事项
sync.WaitGroup 内部使用原子操作维护计数器，并在 Wait() 时进入休眠状态，由 runtime 唤醒。它不是基于 mutex 的忙等，性能开销极低。
- 不能拷贝：
WaitGroup包含互斥锁字段，复制会导致 panic —— 总是传指针或作为包级/局部变量直接使用 - 不能重用后未重置：如果重复使用同一变量，需确保上次
Wait()已返回，且不再有 goroutine 调用Done()；否则可能读到旧计数或引发 panic - 没有超时机制：
Wait()会一直等，生产代码中建议结合context.WithTimeout控制整体等待时限（例如启动 goroutine 时传入 context）
若需超时等待，典型做法是启动一个 timer goroutine 或用 select + time.After：
done := make(chan struct{})
go func() {
wg.Wait()
close(done)
}()
select {
case <-done:
fmt.Println("All finished")
case <-time.After(3 * time.Second):
fmt.Println("Timeout!")
}
当 goroutine 可能 panic 时，如何避免 WaitGroup 卡死？
WaitGroup 本身不处理 panic，如果某个 goroutine panic 且没调用 Done()，Wait() 就永远阻塞。这不是 bug，而是设计使然：它假设你控制着 goroutine 的生命周期。
真正可靠的解法是保证 Done() 总被执行：
- 用
defer wg.Done()—— 这是最简单有效的方案，defer 在 panic 后仍会执行 - 避免在 defer 前做可能 panic 的操作（比如 defer 前解引用 nil 指针）
- 若逻辑复杂，可包裹 recover：
go func() {
defer wg.Done()
defer func() {
if r := recover(); r != nil {
fmt.Printf("Recovered in goroutine: %v\n", r)
}
}()
// 可能 panic 的代码
}()注意：recover 只对当前 goroutine 有效，不影响其他 goroutine，也不会让主流程继续执行失败逻辑 —— 它只是防止 Done() 被跳过。
最常被忽略的一点：很多人把 wg.Add() 放在 goroutine 内部，以为“自己加自己减”，结果因调度延迟导致 Wait() 先执行、计数为 0 直接返回，后续 goroutine 还没开始就结束了。务必记住——Add() 是“预告”，必须提前告知要等几个任务。
