WaitGroup 的等待能否超时：比较完成通知、Context 取消和直接放弃等待

先说结论：sync.WaitGroup 没有超时参数，它只知道计数何时回到零。要让调用方“最多等一段时间”，通常由另一个 goroutine 等待 Wait，再把完成通知交给 select；但超时分支只代表调用方停止等待，不代表后台任务已经停止。

一、先确认 WaitGroup 等待的真实边界

WaitGroup 的核心是一个计数器：启动一项任务前调用 Add(1)，任务结束时调用 Done()，Wait() 阻塞到计数归零。它没有 Wait(timeout) 这样的 API，所以不能把计时器直接塞进 WaitGroup。

常见误解是把“调用方超时”当成“所有 goroutine 已结束”。实际上，Wait 仍可能在另一个 goroutine 中继续等待。若任务还会写共享状态、占用连接或发送结果，超时后的代码必须明确这些动作由谁收尾。

二、用完成通知包一层可超时等待

可以让专门的等待 goroutine 在 Wait() 返回后关闭通知 channel。关闭 channel 是广播式完成信号，调用方用 select 同时等待完成和超时：

func waitWithTimeout(wg *sync.WaitGroup, d time.Duration) bool {
    done := make(chan struct{})
    go func() {
        wg.Wait()
        close(done)
    }()

    select {
    case 

返回 false 时不要立即复用同一个 WaitGroup，也不要把任务结果当成失败或成功。更稳妥的做法是让上层保存任务状态，或者给等待 goroutine 一个明确的生命周期；如果超时路径还要继续处理结果，完成通知 channel 应按业务需要设计缓冲和消费者。

三、超时返回不等于任务被取消

如果任务本身支持取消，应把 Context 传到真正执行 I/O 或循环工作的函数中，而不是只在外层等待结果：

ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()

var wg sync.WaitGroup
wg.Add(1)
go func() {
    defer wg.Done()
    doWork(ctx) // doWork 内部检查 ctx.Done()
}()

finished := make(chan struct{})
go func() { wg.Wait(); close(finished) }()
select {
case 

Context 只能传播取消信号，不能强行杀掉任意 goroutine。doWork 若卡在不支持 Context 的阻塞调用中，外层即使返回超时，资源仍可能未释放。此时应为下游选择支持 Context 的 API，或把任务隔离到可独立回收的边界。

四、按任务能力选择三种方案

可以用下面的判断快速选型：

无论选哪种方案，Add 的时机都要早于对应的 Wait，任务结束必须执行 Done，并且不要复制已经使用过的 WaitGroup。需要多轮复用时，等上一轮的 Wait 返回后再开始下一轮添加任务。

相关问题

WaitGroup 能不能直接设置超时时间？

不能。用完成 channel 或 Context 的 Done 与计时器一起交给 select。

超时后如何确认 goroutine 已经结束？

保留独立的完成通知，或在取消后继续等待收尾；不要仅凭调用方返回就下结论。

为什么超时后不能马上复用 WaitGroup？

因为上一轮任务和 Wait 可能仍在进行。先让任务收敛、Wait 返回，再开始下一轮 Add。

本文依据 Go 官方 sync.WaitGroup 文档与 context 包文档整理。