Go context 取消后为什么仍会继续工作：select 监听、资源释放与收敛检查

调用 cancel() 后，Go 程序里的 goroutine 仍可能继续打印日志、等待网络或持有文件，并不代表 context 失效。取消只是向协作方广播“应该停止”的信号；真正的退出要靠每个工作循环监听 Done()，并在阻塞点、资源释放和退出等待处完成闭环。

绝大多数context取消后仍执行的场景，都不是context本身的失效问题，而是业务代码没有在所有分支点主动感知ctx.Done()信号，同时没有给已持有的各类资源绑定和ctx生命周期同步的释放逻辑，缺少全链路的退出收敛校验环节。

先复现取消已发出但任务仍在跑的现场

常见现场是 HTTP 请求已经返回、上游已经调用 cancel()，但后台 worker 还在消费队列。原因通常不是取消信号没有发出，而是 worker 没有在自己的等待点读取它。

ctx, cancel := context.WithCancel(context.Background())
defer cancel()

go func() {
    for {
        item := 

这段代码有两个独立问题：从 jobs 接收时没有给取消信号留出口；即使循环结束，也没有任何同步手段告诉调用方 goroutine 已经退出。因此“取消已调用”和“工作已停止”是两个不同事实。

把取消信号接入每个可能阻塞的等待点

先给 worker 一个明确的退出协议：接收任务和定时等待都放在 select 中，命中 ctx.Done() 后执行收尾并返回。不要把取消判断只放在循环底部，因为 worker 可能永远阻塞在下一次接收。

func runWorker(ctx context.Context, jobs 

可见的成功状态不是“打印了 cancel”，而是 worker 退出、done.Wait() 返回，且没有新的任务处理记录。任务处理函数也应继续向下传递 ctx，让数据库、HTTP 客户端或自定义重试循环有机会停止。

让网络、定时器和重试逻辑也能收敛

如果 handle 内部使用不可取消的睡眠或自建阻塞队列，外层的 select 仍然只能等它返回。把这些等待改成可取消操作，或者在返回前检查上下文。

func retry(ctx context.Context, limit int) error {
    for attempt := 1; attempt 

HTTP 请求应使用 http.NewRequestWithContext，定时等待应使用可停止的 timer；这样取消时不仅能结束外层循环，也能中断当前阶段的等待。不要用固定 Sleep 代替退出协议。

把资源释放和 goroutine 退出分成两道检查

context 不会替程序关闭文件、连接池、临时目录或自定义句柄。谁创建并拥有资源，谁就要在取消路径里负责释放；如果多个 worker 共享资源，则应由更高层的 owner 统一关闭，避免 worker 互相关闭对方正在使用的对象。

func serve(ctx context.Context, jobs 

这里的顺序要结合资源语义调整：如果 worker 退出前还必须使用资源，就先等待 worker 再关闭；如果关闭资源本身就是让阻塞操作返回，则先关闭再等待。关键是两件事都要有明确的完成条件，并在测试中分别验证。

用退出计数和日志确认是否真的收敛

排查时给每个 worker 记录启动、收到取消、释放资源和退出四类事件，日志字段至少包含 worker 名称、任务标识和退出原因。只记录 cancel called 会把发送信号误当成执行结果。

func waitForWorkers(ctx context.Context, workers *sync.WaitGroup) error {
    finished := make(chan struct{})
    go func() {
        workers.Wait()
        close(finished)
    }()

    select {
    case 

在测试中可以用一个受控 job 和退出计数器，断言取消后计数最终达到 worker 数量；不能依赖“等待几十毫秒后应该退出”这种脆弱时间假设。若使用 errgroup，应同时检查它返回的错误和所有子任务是否已结束。

上线前按这张清单反向检查

• 每个无限循环是否都有 ctx.Done() 分支？
• 队列、网络、定时器和重试等待是否都能被取消？
• 取消是否只传递信号，还是还明确等待了 worker 退出？
• 资源 owner 是否在正确顺序中关闭资源，并记录关闭错误？
• 测试是否断言退出计数、资源关闭和无新增任务，而不是只断言 cancel() 被调用？

相关问题

调用 cancel 后能直接杀掉 goroutine 吗？

不能。goroutine 必须主动读取取消信号并返回；无法控制的阻塞调用需要换成支持上下文的接口或增加可关闭的唤醒机制。

为什么 Done 已经关闭，worker 还多处理了一条任务？

多个 select 分支同时就绪时，运行时可能选择任意一个分支。取消是停止协作的信号，不是对已经取出的任务进行回滚的事务边界；需要严格语义时，要在提交动作前再次检查并设计幂等处理。

取消后应该先 Close 资源还是先等 worker？

取决于资源是否需要被关闭来唤醒阻塞操作。把顺序写成 owner 的协议，并用测试覆盖两种路径；不要让多个 worker 竞相关闭共享资源。

结语

Go context 取消后仍在工作的根因，通常是“信号已发送”被误认为“协程已退出”。把 Done() 接入每个阻塞点，把资源关闭交给明确的 owner，再用等待和退出计数验收，才能把一次取消变成真正可观察、可复查、可收敛的停止流程。