Golang协程如何等待结束

本文深入解析了 Go 语言中使用 sync.WaitGroup 正确等待协程结束的四大核心要点：必须先调用 wg.Add(1) 再启动 goroutine，避免因注册时机错位导致 main 提前退出；务必通过 defer wg.Done() 确保每条退出路径都安全减计数，防止 Wait 永久阻塞；WaitGroup 不可复用，用完即弃，复杂场景应升级为 errgroup.Group；更重要的是厘清边界——WaitGroup 只负责“等待完成”，若需控制协程生命周期（如取消、超时、中断），必须搭配 context.Context 或 channel 才能构建健壮、可响应的并发程序。

WaitGroup 必须先 Add 再 go，否则 main 可能提前退出

绝大多数 goroutine 看似“跑完了”，但 main 却早已退出——根本原因是 wg.Add(1) 和 go 不是原子操作。协程还没来得及注册自己，wg.Wait() 就已返回，计数器还是 0。

• ✅ 正确做法：在 go 语句前调用 wg.Add(1)，哪怕只启一个协程也要先加再启
• ✅ 动态数量（比如遍历切片启多个）：循环里先 wg.Add(1)，再 go func() { ... }()
• ❌ 错误写法：go func() { wg.Add(1); ... wg.Done() }() —— 这会导致漏注册、panic 或静默失败
• ⚠️ 注意：wg.Add(-1) 会直接 panic，手抖写反了就崩

Done 要确保每条退出路径都执行到

wg.Done() 是减计数器的唯一安全方式，但它不会自动执行——你得手动放，而且得放在所有可能 return 的前面，否则计数器卡住，wg.Wait() 永远不返回。

• ✅ 推荐写法：defer wg.Done()，且必须放在 goroutine 函数体第一行（不是 defer 块里嵌套其他逻辑）
• ✅ 如果有多个 return 分支（比如 error 处理），defer 仍能覆盖全部路径
• ❌ 避免写成：if err != nil { return }; wg.Done() —— err 分支就漏掉了
• ⚠️ wg.Done() 本质是 wg.Add(-1)，重复调用或调用次数少于 Add 次数，都会导致 Wait 永久阻塞或 panic

WaitGroup 不可复用，用完就得换新实例

wg.Wait() 返回后，内部计数器归零；此时若再次调用 wg.Add(n)，Go 1.21+ 版本会 panic，旧版本行为未定义——这不是 bug，是设计使然。

• ✅ 简单场景：每次等待一批新协程，就声明新的 var wg sync.WaitGroup
• ✅ 复杂场景（需错误传播、取消、重试）：改用 errgroup.Group，它自动管理 Add/Done，还带 ctx 和错误聚合
• ❌ 别试图“重置” WaitGroup：没有 Reset() 方法，也不该靠反射或 unsafe 强行复用
• ⚠️ errgroup.Group 要引入 golang.org/x/sync/errgroup，简单等待任务没必要为此加依赖

想等协程结束 ≠ 只用 WaitGroup，别混淆“等待完成”和“通知退出”

sync.WaitGroup 只回答一个问题：“它们干完活了吗？”，它不负责告诉协程“该停了”。如果你需要控制协程中途退出、超时中断、或响应取消信号，WaitGroup 本身无能为力。

• ✅ 等“做完”：用 WaitGroup，干净利落
• ✅ 控制“别做了”：用 context.Context（推荐）或 chan struct{} 配合 select
• ✅ 两者结合：WaitGroup 等结束，Context 控制生命周期，比如 go func(ctx context.Context) { defer wg.Done(); for { select { case
• ⚠️ 别把 WaitGroup 当退出开关——它没通道、没上下文、不传信号，硬凑只会让逻辑缠在一起，难测难调

WaitGroup 看似简单，但 Add/Done 的时序、复用边界、与退出机制的职责划分，三处最容易出问题。实际写的时候，宁可多写一行 wg.Add(1) 放前面，也别赌调度顺序；宁可多引一个 errgroup，也别在 WaitGroup 上堆逻辑补丁。

本篇关于《Golang协程如何等待结束》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！