Go 问答：context.WithCancel 后如何确认子协程真正退出

服务收到超时或关闭信号后，调用了 cancel()，日志却迟迟没有出现“worker exited”。这里最容易混淆的一点是：context.WithCancel 只负责发出取消信号，不负责等待接收方结束。要确认子协程真的退出，必须让 worker 监听 ctx.Done，在退出路径执行 defer wg.Done，最后由主流程调用 Wait 收口。

真正可靠的退出确认是一个可等待的协议：cancel() 触发，worker 从 ctx.Done 返回，defer wg.Done 归还计数，主流程的 Wait 完成后才算收尾。

先量出“取消已调用但协程未收尾”的基线

先写一个故意不等待的版本。它能看到取消函数返回，却看不到 worker 的退出时刻：

package main

import (
    "context"
    "fmt"
    "time"
)

func main() {
    ctx, cancel := context.WithCancel(context.Background())
    go func() {
        for {
            select {
            case 

这段程序的两个输出没有顺序契约，进程甚至可能在 worker 打印前就结束。把 time.Sleep 塞到主流程里只能让现象“看起来稳定”，不能证明每条退出路径都完成。

让取消信号真正走到 worker 的阻塞点

把退出条件放在 worker 自己的 select 中，主流程同时注册一个等待组。图片中的 main、worker、ctx.Done 和 defer wg.Done 都对应下面这段真实代码节点。

func runWorker(ctx context.Context, wg *sync.WaitGroup) {
    defer wg.Done()
    for {
        select {
        case 

关键不是把取消检查写在循环外，而是让每次可能等待的地方都能回到 ctx.Done。如果实际工作调用本身会阻塞，就要使用支持 context 的 API，或在外层增加可中断的通道协议。

用 Wait 把退出变成可验收的结果

完整的主流程如下。Wait 不是延时器，它只会在所有已登记的 worker 执行过 Done 后返回：

func main() {
    ctx, cancel := context.WithCancel(context.Background())
    var wg sync.WaitGroup

    wg.Add(1)
    go runWorker(ctx, &wg)

    cancel()
    wg.Wait()
    fmt.Println("all workers exited")
}

复测时可以在 cancel() 前后各记一次时间，再在 Wait 返回后记录最终状态。预期顺序是“cancel returned”先出现，“all workers exited”后出现；后者出现时，worker 的等待计数已经归零。不要把 goroutine 数量、日志先后或一个经验性的 100 毫秒 sleep 当成完成信号。

三个常见边界会让 Wait 看起来失效

• 忘记 Add。 如果先启动 goroutine 再调用 Add，主流程可能抢先进入 Wait，形成竞态；应在启动前完成登记。
• 漏掉 Done。 worker 在某个错误分支直接 return 时，如果没有入口处的 defer wg.Done，主流程会永久等待。
• 阻塞调用不响应 context。 worker 只在外层循环检查 ctx.Done，但内部调用一直不返回，取消信号仍然只能排队等候。

另外，context.Context 不应被保存到结构体里长期复用，也不要把 nil context 传给函数。需要取消的操作应把 context 作为第一个参数，并让真正执行 I/O 或等待的下层函数继续接收它。

用一次可重复复测替代固定 sleep

可以把验收拆成三条日志：worker 开始、worker 观察到 ctx.Done、主流程 Wait 返回。连续运行多次，最后一条都必须出现在第二条之后；若偶发缺失，优先检查是否存在未登记的 goroutine、遗漏 Done 或不可取消的阻塞调用。

这套判断关注的是生命周期正确性，不是吞吐基准。真实服务还应把请求超时、下游调用取消、连接关闭和最终资源释放分别记录，避免只看到一个“请求结束”日志就误以为所有后台工作都已清理。

相关问答

调用 cancel 后能直接读取 ctx.Err 吗？

可以读取到取消状态，但 ctx.Err 只能说明取消已经传播到 context，不能证明 worker 已经执行完清理；退出确认仍应等待 Wait 或其他明确的完成信号。

为什么不推荐用 time.Sleep 等待协程退出？

sleep 只是假设一个时间窗口，机器负载、调度和下游阻塞都可能让它失效。用 Wait 等待实际完成，才能把时序变成程序契约。

一个 worker 也需要 WaitGroup 吗？

不一定，也可以使用一个完成通道或其他明确的 join 信号；但无论选哪种方式，都要让主流程等待 worker 的真实退出，而不是等待一段固定时间。

收口检查

排查“取消后子协程还在跑”时，依次看四件事：worker 是否监听 ctx.Done，阻塞调用是否支持取消，defer wg.Done 是否覆盖所有返回路径，以及主流程是否真正等待 Wait。这四项都成立，cancel() 才不再只是一个无确认的通知动作。