Go context取消后下游循环仍运行的检查清单

调用 cancel() 后，下游循环仍运行，通常不是 context 失效，而是取消信号没有覆盖真正的阻塞点或循环边界。CancelFunc 只会关闭派生 context 的 Done()，不会强行终止 goroutine，也不会等待它退出。排查时要沿着“传递 context、阻塞调用、channel 边界、退出返回值”四层往下看。

先判断取消信号有没有真正传到下游

派生 context 的取消会向子 context 传播，但函数只有主动读取 Done() 或调用支持 context 的 API，才会停止工作。最常见的断点是：上层把 ctx 传给了生产者，下游处理函数却改用 context.Background()；或者函数签名带了 ctx，却没有把它继续传入数据库、HTTP 请求和内部循环。

func run(ctx context.Context, in 

这里的关键不是把 ctx.Err() 写得更多，而是确认每一层没有替换 ctx。若某个第三方 API 不支持 context，只能在它返回前等待；这时应把它视为“不可及时取消”的边界，而不是继续增加无效的 select。

阻塞点和循环边界要分别检查

下游“还在运行”有两种表现：循环卡在一次慢调用里，或调用已经返回但循环在 channel 上继续等待。前者要求把 ctx 传给可取消 API，后者要求在每次接收、发送前都让取消分支有机会被选中。

例如生产者不能只写 out 。当消费者已经退出时，这条发送会让生产者永久阻塞：

func produce(ctx context.Context, out chan

如果 ctx.Done() 已关闭，同时输入或输出也已经就绪，select 可能随机选择任一分支，所以取消并不保证零额外处理。对不能重复执行的副作用，应在真正提交前再检查状态，并设计幂等键或补偿逻辑。

用退出顺序确认到底是谁没有停

检查清单可以按下面顺序执行：第一，确认创建派生 context 的函数有 defer cancel()；第二，确认每个长期函数都接收并继续传递 ctx；第三，搜索所有无 ctx 的阻塞调用、裸 channel 发送和裸 channel 接收；第四，让消费者先退出，再观察生产者是否能收到取消并返回；第五，在测试中记录每个 goroutine 的退出日志。

不要把“调用了 cancel”当成“工作已经完成”。官方 context 文档明确说明，CancelFunc 不等待工作停止；上层如果需要等待，应配合 sync.WaitGroup、errgroup 或明确的 done channel。返回错误时，context.Canceled 表示主动取消，context.DeadlineExceeded 表示截止时间到期，两者都比静默吞掉退出更容易定位。

常见问题

为什么循环里已经有 ctx.Done() 仍然不退出？

循环可能卡在进入 select 之前的不可取消函数里，也可能卡在没有 ctx 分支的发送或接收上。先定位 goroutine 的阻塞栈，再补对应边界。

能不能在 cancel 后直接关闭输入 channel？

不能由不拥有 channel 的一方随意关闭。关闭应由发送方负责；取消只负责通知，接收方用 Done 退出，发送方用可取消发送避免互相等待。

如何确认下游真的停止了？

让函数返回 ctx.Err() 或明确错误，等待 goroutine 完成，再结合测试中的退出计数和 goroutine profile 观察是否仍有增长。

归纳起来，Go context 取消后下游循环仍运行时，优先检查“是否传递同一个 ctx、阻塞调用是否可取消、接收和发送是否都监听 Done、上层是否等待退出”四项。补齐这四层，通常比在循环外再调用一次 cancel() 更有效。