Context 已取消但函数仍不退出，通常漏查了哪些阻塞点

我第一次遇到这个问题时，日志已经打印了 context canceled，监控里那批 goroutine 却迟迟不降。后来才发现，代码把“Context 已取消”误当成了“所有阻塞调用已经被打断”。这两件事在 Go 里并不等价。

先给结论：取消 Context 只会关闭 Done() 返回的通道，并让 Err() 返回原因。它不会像线程中断那样自动唤醒任意 channel 收发、WaitGroup.Wait、Mutex.Lock、time.Sleep 或不支持 Context 的 I/O。函数要退出，必须自己观察取消信号，或者进入一个明确支持 Context、deadline、关闭资源等中断机制的调用。

官方资料：https://pkg.go.dev/context。Go 标准库把 Context 定义为跨 API 边界传递 deadline、取消信号和请求级值的载体；它是协作式取消协议，不是强制终止 goroutine 的开关。

问题原文：ctx.Err 已经非空，为什么函数还挂着

最容易产生误判的代码通常像这样：

func load(ctx context.Context, jobs 

调用方执行 cancel() 后，ctx.Err() 的确会变成 context.Canceled。但当前 goroutine 正停在接收表达式上，根本没有机会执行下一行检查。真正决定退出速度的不是“取消发生了多久”，而是代码多久能重新获得一次观察 ctx.Done() 的机会。

修复时要把取消信号和可能阻塞的操作放在同一个等待点：

func load(ctx context.Context, jobs 

常见误区一：只在函数入口检查一次 Context

入口处的 if err := ctx.Err(); err != nil 只能拒绝一个“开始前就已经取消”的任务。函数随后一旦进入长循环、阻塞收发或外部调用，这次检查就失效了。检查点应该贴近每个可能长时间等待的位置，而不是集中写在函数开头。

循环处理时，可以把每轮等待写成可取消的 select：

func worker(ctx context.Context, in 

这里有两个等待点，接收和发送都要能取消。很多泄漏只修了前半段：worker 能停止取新任务，却在把最后一个结果发送给已经退出的消费者时再次卡住。

常见误区二：传进来的不是那个被取消的 Context

第二类问题不是“没检查”，而是取消链在中途被换掉了。重点搜索下面几种写法：

• 下游函数内部重新使用 context.Background() 或 context.TODO()；
• 创建派生 Context 时，父 Context 取错了变量；
• 启动 goroutine 时没有把当前 Context 作为参数传入，闭包后来引用了另一个值；
• 使用 context.WithoutCancel 后仍期待父级取消继续传播。

WithoutCancel 是有意切断取消、deadline 和错误传播的工具，其返回 Context 的 Done 为 nil。它适合确实需要脱离请求生命周期的收尾任务，但不能当作普通的“复制 Context”。如果任务仍应随请求结束，就继续从原始 ctx 派生。

真正容易漏掉的四类阻塞点

1. 没有 select 的 channel 发送与接收

无缓冲 channel 没有对端时会阻塞；有缓冲 channel 满了以后发送也会阻塞。单独执行 ch 或 时，Context 取消不能插入这次等待。解决方法不是在操作前后各检查一次，而是把 channel case 与 ctx.Done() 放进同一个 select。

还要特别检查 nil channel。对 nil channel 的发送和接收会一直阻塞；在 select 中，nil channel 对应的 case 会被禁用。动态开关 channel 时如果把变量设成 nil，需要保证仍有 ctx.Done() 或其他可唤醒 case。

2. WaitGroup、Mutex、Cond 等同步原语

WaitGroup.Wait、Mutex.Lock 和 Cond.Wait 都不接收 Context。取消外层 Context 不会让它们自动返回。看到 goroutine 堆栈里长期停在 semacquire，应当回头检查谁没有执行 Done、谁持锁未释放，或者条件变量是否遗漏广播。

不要简单地再开一个 goroutine 包住 Wait()，然后外层 select 超时就返回。这样最多让调用者先走，内部等待的 goroutine 仍可能永久存在。更可靠的做法是让每个 worker 本身都接收同一个 Context，并保证所有退出分支都执行 Done；锁内只做短操作，把可阻塞 I/O 移到锁外。

3. time.Sleep、ticker 与不可取消退避

time.Sleep 到点前不会响应 Context。重试退避、限速等待和定时轮询应该使用 Timer，并与 ctx.Done() 同时等待：

func waitRetry(ctx context.Context, delay time.Duration) error {
    timer := time.NewTimer(delay)
    defer timer.Stop()

    select {
    case 

长期 ticker 还要由创建方停止。否则即使消费循环退出，相关资源与发送活动仍可能存活到更晚。

4. 不支持 Context 的 I/O 或第三方调用

函数参数里有 ctx，不代表最底层 I/O 就支持取消。要逐层检查是否真正使用了带 Context 的 API：

• HTTP 客户端使用 http.NewRequestWithContext 或 Request.WithContext。官方文档说明，出站请求的 Context 控制获取连接、发送请求以及读取响应头和响应体的整个生命周期。
• 数据库使用 QueryContext、ExecContext 或 BeginTx，同时确认驱动实现支持取消。database/sql 文档明确提醒，不支持 Context 取消的驱动会等查询真正结束后才返回。
• 裸 net.Conn、io.Reader 或自定义协议没有 Context 参数时，使用读写 deadline，或在取消时安全关闭专属连接来解除阻塞。不要随意关闭多个请求共享的资源。
• 外部进程使用 exec.CommandContext 并设计好子进程和管道的收尾；普通 exec.Command 不会因为业务 Context 取消就自行退出。

context.AfterFunc 可以在取消发生时触发适配动作。标准库文档就给出了通过设置连接读取 deadline 来唤醒阻塞 Read 的例子。关键是适配动作必须幂等、资源归属清楚，并且不会误伤其他仍在使用同一资源的请求。

正确做法：从 goroutine 堆栈反查阻塞点

如果日志只能证明取消函数执行过，下一步不要继续增加 ctx.Err() 打印，而是看 goroutine 当前真正停在哪里。线上通常可以通过既有的诊断入口采集 goroutine profile；本地测试也可使用 runtime/pprof.Lookup("goroutine") 输出堆栈。排查时关注等待原因和业务栈顶：

• chan send：消费者可能先退出，生产者还在发送；
• chan receive：生产者未关闭 channel，或接收没有取消分支；
• semacquire：常见于 WaitGroup、Mutex 或其他同步等待；
• IO wait：检查 socket、pipe、DNS、数据库驱动和 deadline；
• select：确认取消 case 使用的是同一个 Context，且没有进入另一个不可取消调用。

堆栈比“取消日志”更有价值，因为前者回答“现在被什么调用卡住”，后者只回答“某个 cancel 曾经被调用”。把等待原因映射回代码后，再为那个具体阻塞点设计取消路径。

边界情况：select 里有 ctx.Done 仍可能退不出来

出现这种情况时，我会继续检查三件事。第一，代码是否在进入 select 前就卡在耗时计算或不可取消调用中；第二，选中的普通 case 内部是否又调用了阻塞函数；第三，取消后是否进入清理阶段，却在等待另一个没有退出协议的 goroutine。

CPU 密集循环也不会被 Context 抢占成业务级返回。Go 调度器可以调度 goroutine，但不会替业务函数返回错误。对于长时间计算，应在合适的批次边界检查 ctx.Err()，检查频率在退出延迟和循环开销之间取舍。

另外，不要关闭 ctx.Done()，也不要由接收方随意关闭业务 channel。Context 的取消由创建它的 CancelFunc 管理；业务 channel 通常由唯一发送方关闭。把所有权规定清楚，比在各处补 recover 更能避免停不下来的并发代码。

最终排查清单

1. 当前函数收到的 Context，是否真的是调用方取消的那一个。
2. 是否在中途使用 Background、TODO 或 WithoutCancel 切断了取消链。
3. 每个可能阻塞的 channel 发送和接收，是否与 ctx.Done 位于同一个 select。
4. 是否卡在 WaitGroup.Wait、Mutex.Lock、Cond.Wait 或等待未关闭的 channel。
5. 重试退避是否仍使用不可取消的 time.Sleep。
6. HTTP、SQL、进程和第三方客户端是否真正调用带 Context 的方法。
7. 底层驱动或库不支持 Context 时，是否有 deadline、关闭资源或其他安全适配手段。
8. 取消后是否仍有生产者向已退出的消费者发送结果。
9. goroutine 堆栈显示的最终等待原因，是否与设计中的退出协议一致。

因此，看到 context.Canceled 只能证明取消信号已经产生，不能证明整条调用链已经收尾。把每个阻塞点都写成“完成、取消或资源关闭三者至少有一个能唤醒”，函数才会真正按预期退出。

延伸问题

Context 取消后，正在执行的普通函数会被强制停止吗？
不会。普通函数需要主动检查 Context，或调用支持 Context、deadline、关闭资源等中断机制的 API。

可以用一个 goroutine 包住阻塞调用，再 select ctx.Done 吗？
调用方可以更早返回，但被包住的调用如果没有中断机制，内部 goroutine 仍可能泄漏。只有能保证结果通道不会反向阻塞、底层调用最终会结束时才适合这样封装。

为什么 QueryContext 取消后数据库还在运行？
除了检查是否传入正确 Context，还要确认数据库驱动与服务端协议支持取消。标准库文档明确指出，不支持 Context 取消的驱动只能等查询结束。

context.WithoutCancel 什么时候用？
用于明确需要脱离父请求取消的任务，例如受控的短收尾；它返回的 Context 没有 deadline、Err，Done 也是 nil，因此必须由新的生命周期和超时约束接管。

参考资料

• Go context 标准库：https://pkg.go.dev/context
• Go net/http 标准库：https://pkg.go.dev/net/http
• Go database/sql 标准库：https://pkg.go.dev/database/sql
• Go database/sql/driver 标准库：https://pkg.go.dev/database/sql/driver
• Go Blog《Go Concurrency Patterns: Context》：https://go.dev/blog/context