如何等待多个goroutine完成_Go并发等待机制解析

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 main 
import ( "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: %sn", 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: %vn", r)         }     }()     // 可能 panic 的代码 }()
注意：recover 只对当前 goroutine 有效，不影响其他 goroutine，也不会让主流程继续执行失败逻辑 —— 它只是防止 Done() 被跳过。
最常被忽略的一点：很多人把 wg.Add() 放在 goroutine 内部，以为“自己加自己减”，结果因调度延迟导致 Wait() 先执行、计数为 0 直接返回，后续 goroutine 还没开始就结束了。务必记住——Add() 是“预告”，必须提前告知要等几个任务。