Go context 取消后 Handler 未退出的阻塞定位

Go HTTP 请求已经取消，Handler 却迟迟不退出，通常不是 context.Context 失效，而是取消信号没有被正在等待的那段代码消费。排查时先看 r.Context().Done() 是否关闭，再确认 Handler 内部的数据库调用、下游请求、channel、锁和响应写入是否都能返回。

这里有一个容易混淆的点：请求 Context 被取消，只代表“这次工作已经不值得继续”，不会强行中断任意 goroutine，也不会把普通的阻塞函数变成可取消函数。定位目标是找到仍在等待的具体位置。

先确认取消信号是否真的到达

对于服务端请求，r.Context() 会随着客户端连接关闭、HTTP/2 请求取消，或 ServeHTTP 返回而取消。第一步不要直接猜业务函数，先在 Handler 入口和关键返回点记录状态。

func handler(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()

    // 这个 goroutine 只观察取消信号，便于确认问题发生在入口还是下游。
    go func() {
        

如果取消日志能出现，而 Handler 的返回日志没有出现，说明信号已经到达，阻塞发生在 loadResult 或它调用的下游。若连取消日志都没有，再检查测试是否真的关闭连接、是否使用了正确的请求对象，以及 Handler 是否已经提前返回。

沿 Handler 的阻塞点拆分检查

把 Handler 看成一条等待链，而不是一个整体。每个等待点都要回答两个问题：它是否拿到了当前 Context？它是否在等待时监听了取消信号？

数据库或下游 HTTP 调用

如果调用 API 没有 Context 版本，取消请求不会自动终止它。优先使用 QueryContext、ExecContext，或用 NewRequestWithContext 创建下游请求。

func loadResult(ctx context.Context) (string, error) {
    // 把请求上下文继续传给数据库，客户端断开时让驱动有机会停止等待。
    rows, err := db.QueryContext(ctx, "SELECT value FROM items WHERE id = ?", 7)
    if err != nil {
        return "", err
    }
    defer rows.Close() // 无论查询成功还是取消，都释放结果集资源。

    if !rows.Next() {
        return "", rows.Err()
    }
    var value string
    if err := rows.Scan(&value); err != nil {
        return "", err
    }
    return value, nil
}

这里的判断重点不是“调用了 Context API 就一定立即返回”，而是确认具体驱动、传输层和超时配置都能响应取消。若调用方已经返回错误，但 Handler 仍不退出，就继续向上检查是否有额外的重试或收尾等待。

channel 等待

最常见的阻塞写法是直接从 channel 接收：value := 。如果生产者因为请求取消而提前退出，消费者会永久等待。改成同时监听 ctx.Done()。

func waitResult(ctx context.Context, ch 

锁和不可取消的临界区

sync.Mutex.Lock 本身不接收 Context。若锁竞争是主要等待点，不能简单地在旁边再启动一个监听 goroutine 就认为 Handler 可取消；那个监听只会记录日志，不能替你解除锁等待。应缩短持锁区、避免在锁内执行网络或数据库操作，并用指标记录等待时间。

修复不响应取消的等待

修复的原则是让取消能力跟着调用链向下传递，并让每个自建等待都有退出分支。一个小型工作函数可以这样组织：

func run(ctx context.Context, jobs 

不要把 context.WithoutCancel 用来“修复” Handler 不退出；它会切断取消链，适合明确需要脱离请求生命周期的独立工作，不适合让请求内任务继续占用资源。若确实要异步执行，应该把任务交给有独立生命周期的队列或 worker，并为它定义自己的超时和关闭策略。

识别 Handler 外的假象

观察到“请求还没结束”不一定等于 Handler 仍卡在业务代码里。可以把日志分成三个时间点：收到取消、业务函数返回、Handler 返回。中间件可能在 Handler 返回后才写访问日志；响应写入也可能因为网络缓冲造成时间差。

另一个常见误区是 Handler 启动了后台 goroutine，然后等待一个不会关闭的完成 channel。请求 Context 取消后，后台 goroutine 如果没有监听 Done()，它会泄漏；即使 Handler 最终返回，进程中的工作仍然没有结束。

func startWorker(ctx context.Context) 

形成可复用的排障清单

可以按下面的顺序定位，而不必一开始就给所有函数加日志：

1. 确认客户端或测试确实触发了取消，并记录 ctx.Err()。
2. 在 Handler 调用链的每个长耗时边界前后记录开始和返回时间。
3. 搜索没有接收 Context 的数据库、HTTP、文件和重试调用。
4. 搜索直接接收 channel、等待 WaitGroup、获取锁和等待后台完成通知的位置。
5. 确认取消错误没有被包装、吞掉后又触发无限重试。
6. 最后检查后台 goroutine 是否有自己的退出条件和资源清理。

一句话总结：context 取消后 Handler 未退出，先证明取消信号已经到达，再沿“当前正在等待什么”这条线定位。Context 不能强制打断普通阻塞；只有把它传入可取消的 API，或在自建等待中显式选择 Done()，Handler 才能真正结束。

相关问题

为什么收到 context.Canceled 后 Handler 还没返回？

因为某个下游等待没有监听 Context，或者错误返回后仍进入了重试、锁等待和清理流程。先看返回日志和阻塞点，不要只看取消日志。

监听 ctx.Done() 能取消 sync.Mutex.Lock 吗？

不能。它只能让你在其他可选等待中提前返回；锁本身需要通过缩短临界区、调整共享状态设计或避免锁内慢操作来降低阻塞。

Handler 返回后还能继续使用请求 Context 吗？

不应依赖它做后台工作，因为服务端请求 Context 会在 ServeHTTP 返回时取消。需要异步处理时，为独立任务建立明确的生命周期。

官方参考：https://pkg.go.dev/context、https://pkg.go.dev/net/http#Request.Context、https://go.dev/doc/database/cancel-operations