如何在 Go 中编写一个等待所有后台协程函数安全结束的退出逻辑-Golang-PHP中文网

sync.waitgroup 是 go 中唯一可靠管理协程生命周期的方式，需严格遵循 add/done 配对、避免负计数、禁止外部重置、慎用 defer done，并结合 context 实现超时控制与 panic 恢复。

如何在 go 中编写一个等待所有后台协程函数安全结束的退出逻辑

用 `sync.WaitGroup` 管理协程生命周期是唯一可靠方式

Go 没有内置的“等待所有 goroutine 结束”机制，sync.WaitGroup 是标准库中唯一被设计用于此目的的同步原语。它不依赖超时或轮询，而是通过显式计数控制退出时机。误用 time.Sleep 或空 select{} 会导致程序提前退出或卡死。

关键点：必须在启动 goroutine 前调用 WaitGroup.Add(1)，且只能在 goroutine 内部调用 WaitGroup.Done() —— 如果在主 goroutine 中提前调用 Done()，会导致 Wait() 立即返回，后台任务还没开始就结束。

WaitGroup 的计数器是 int 类型，不能为负；多次调用 Done() 而没配对 Add() 会 panic
不要把 WaitGroup 作为参数传给 goroutine 后，在外部修改其字段（比如直接赋值 wg = sync.WaitGroup{}），这会破坏内部状态
若需动态增减任务数（如 worker pool 场景），每次新增任务前都必须调用 Add(1)，哪怕在 goroutine 内部

避免在 defer 中调用 `WaitGroup.Done()` 导致的 panic

常见错误是写成：go func() { defer wg.Done(); ... }()。这看似简洁，但一旦 goroutine 内部 panic，defer 仍会执行 Done()，而此时 WaitGroup 可能已被主 goroutine 调用过 Wait() 并清零，导致 “negative WaitGroup counter” panic。

更安全的做法是确保 Done() 总在正常逻辑路径末尾显式调用，或包裹 recover：

go func() {
    defer func() {
        if r := recover(); r != nil {
            // 日志记录 panic，但依然要 Done
            log.Printf("worker panicked: %v", r)
        }
        wg.Done()
    }()
    // 实际工作...
}()