Go HTTP 服务端Request Context 在客户端断开后没有结束怎么办

如果 Go HTTP 服务端在客户端已经断开后，后台工作仍然没有结束，先检查处理器是否真的使用了 r.Context()，以及这个 context 是否一路传到了阻塞操作。服务端请求的 context 会在客户端连接关闭、HTTP/2 请求被取消，或者 ServeHTTP 返回时取消；它不会替你终止一个完全不监听 context 的 goroutine。

本文讨论的不是“所有后台任务都必须随请求取消”，而是请求级工作误用了独立 context，导致资源和计算继续占用的排查边界。

官方文档入口：https://pkg.go.dev/net/http#Request.Context

升级范围：把请求级取消信号交给 Request.Context

旧代码常见的做法是从 ResponseWriter 断言 http.CloseNotifier，或者在处理器内部重新创建 context.Background()。前者已经被官方标记为弃用，后者则切断了 HTTP 请求和下游工作的联系。迁移时应把请求 context 当作这次请求的取消契约，并在下游 API 中保留它。

旧代码风险：看似监听断开，实际没有传到工作函数

先找两类断点：一类是处理器里出现了 context.Background() 或 context.TODO()，另一类是启动 goroutine 后只等待业务 channel，却没有任何 Done 分支。即使 HTTP 层已经取消请求，后面的代码没有读取这个信号，也不会自动返回。

func handler(w http.ResponseWriter, r *http.Request) {
    // 这个独立 context 与当前 HTTP 请求没有取消关联。
    ctx := context.Background()
    go func() {
        // 没有监听 ctx.Done，客户端断开也不会让循环自行结束。
        runLongWork(ctx)
    }()
    w.WriteHeader(http.StatusAccepted)
}

另一种旧写法是断言 http.CloseNotifier，然后只把通知写入自定义 channel。它不仅增加了适配代码，也容易让下游函数继续接收一个没有取消能力的参数。迁移时不要只替换检测语句，要检查取消信号是否到达真正的 I/O 或循环位置。

新写法：从 r.Context 传到每个可取消的下游

最小改法是让业务函数接收 context.Context，并在循环或等待点监听 Done。如果下游库本身支持 context，优先把同一个请求 context 传给它，而不是在中间层重新创建一个永不取消的根 context。

func handler(w http.ResponseWriter, r *http.Request) {
    // 服务端请求 context 与客户端连接和 HTTP/2 请求生命周期关联。
    if err := runLongWork(r.Context()); err != nil {
        // 客户端断开通常不需要再写一个新的业务响应。
        if errors.Is(err, context.Canceled) {
            return
        }
        http.Error(w, "处理失败", http.StatusInternalServerError)
        return
    }
    w.WriteHeader(http.StatusNoContent)
}

func runLongWork(ctx context.Context) error {
    for {
        select {
        case 

示例的关键不是把所有任务都写成循环，而是保持一条连续的 context 链。数据库查询使用 QueryContext，出站 HTTP 请求使用 http.NewRequestWithContext，自定义阻塞函数则在等待 channel、锁或 I/O 的位置增加取消分支。

回归检查：确认结束的是请求级工作

迁移后按下面的边界设计检查项，不要只看处理器有没有一行 r.Context()：

• 客户端在响应完成前断开时，处理器内的等待点能收到 Done，并释放临时资源。
• 正常完成请求时，不把业务成功误判为 context.Canceled。
• HTTP/2 场景按请求取消处理，不再依赖只覆盖部分连接实现的旧通知接口。
• 所有数据库、出站 HTTP 和自定义阻塞函数都检查是否接收了同一条请求 context。
• 如果任务必须在响应返回后继续完成，显式把它移交给独立队列或生命周期，而不是偷偷使用 Background。

还要留意 ServeHTTP 返回这一边界：请求 context 的取消并不等于所有脱离处理器的后台任务都应被强行停止。任务的所有权要先说清楚，再决定使用请求 context 还是独立任务 context。

迁移清单：从连接通知改到请求语义

1. 删除只为检测断开的 CloseNotifier 适配，先确认目标版本与代码路径。
2. 把处理器中的根 context 替换为 r.Context()，必要时只在其上派生超时。
3. 为业务函数、数据库调用和出站 HTTP 调用补上 context 参数。
4. 在 channel、循环和阻塞 I/O 的等待处处理 ctx.Done() 与 ctx.Err()。
5. 为必须脱离请求完成的任务建立明确的队列或任务生命周期，并记录它与请求的关联 ID，而不是复用请求 context。

一句话总结：客户端断开后 Request Context 没有结束，通常不是 net/http 没发出取消信号，而是代码没有使用这条信号，或者在中间层把它换成了不会取消的 context。

两个容易混淆的问题

为什么 goroutine 还在运行？ goroutine 不会被 context 直接杀死；只有它主动读取 Done、调用支持 context 的 API，或被业务自己的停止机制收尾，才会退出。

是不是所有任务都该绑定 r.Context？ 只有属于这次请求的工作适合绑定。需要可靠完成的异步任务应在请求返回前完成投递，再由独立任务上下文负责后续执行。