客户端断开后 Go Handler 何时会停：用 Request.Context 串起请求与下游调用

线上接口偶尔会出现这样的现象：浏览器早已关闭，服务端日志里的 Handler 却还在等待下游结果。结论先说清楚：客户端断开后，Go 的 Handler 不会把任意业务代码强行杀掉；r.Context() 会发出取消信号，只有循环、HTTP 客户端、数据库驱动等协作方监听并传递这个信号，工作才会尽快收尾。

把 r.Context() 当作这次请求的取消根节点，所有请求范围内的下游调用都接收它；收到 context.Canceled 或 context.DeadlineExceeded 后记录原因并返回，才能避免客户端已经离开、资源仍被占用。

• 保护对象：连接、响应体、数据库连接和请求 goroutine。
• 风险边界：Context 只能协作式取消，不能中断一段不检查信号的 CPU 代码。
• 落地结果：请求取消、超时和正常完成在日志中可区分。

下面按请求边界、下游传播和复查证据拆开看。官方定义可参考 net/http.Request.Context 与 context.WithCancel。

先把请求生命周期和取消边界画出来

对传入服务端请求，r.Context() 始终非空。HTTP/1 客户端连接关闭、HTTP/2 请求被取消，或者 ServeHTTP 返回时，这个 Context 会被取消。这里的“取消”是关闭 Done() 通道并让 Err() 变成错误，不是运行时替你终止任意 goroutine。

因此 Handler 应把请求 Context 作为唯一的取消根：

func handler(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()
    if err := loadProfile(ctx); err != nil {
        if errors.Is(err, context.Canceled) {
            log.Printf("request canceled")
            return
        }
        http.Error(w, "upstream failed", http.StatusBadGateway)
        return
    }
    fmt.Fprintln(w, "ok")
}

保护边界在 handler 和 ctx，下游工作在另一个边界内。只要 loadProfile 不接收并使用这个 Context，取消信号就会在入口处断掉。

为什么只检查一次 Err 还不够

ctx.Err() 适合在某个检查点判断当前状态，但耗时循环更应该监听 Done()。Context 不会替你抢占正在执行的函数，代码必须在等待、批处理或重试之间留出取消入口。

func scan(ctx context.Context, jobs 

这段代码的关键不是 select 本身，而是每轮工作都把 Context 继续交给 handleOne。如果 handleOne 内部又启动 goroutine，却只接收 context.Background()，外层取消仍然无法覆盖它。

把 Context 传到 HTTP 与数据库下游

传出 HTTP 请求不要使用没有 Context 的快捷调用。用 http.NewRequestWithContext 创建请求，客户端就能在建立连接、发送请求和读取响应期间响应取消：

func loadProfile(ctx context.Context) error {
    req, err := http.NewRequestWithContext(
        ctx, http.MethodGet, "https://api.example.test/profile", nil,
    )
    if err != nil {
        return err
    }
    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        return err
    }
    defer resp.Body.Close()
    if resp.StatusCode >= http.StatusBadRequest {
        return fmt.Errorf("profile status: %s", resp.Status)
    }
    return nil
}

// 数据库驱动应使用类似 db.QueryContext(ctx, query, args...) 的接口。

数据库调用同理：优先选择驱动提供的 QueryContext、ExecContext 或同类 API。若某个库只提供不接收 Context 的阻塞方法，就不能承诺客户端断开会立刻中止那次操作，至少要在服务层记录这个缺口。

用日志和测试确认取消真的生效

处理错误时不要只打印一条“请求失败”。用 errors.Is 区分客户端取消和服务端超时，并在拿到响应后关闭 Body：

if err := loadProfile(ctx); err != nil {
    switch {
    case errors.Is(err, context.Canceled):
        log.Printf("request canceled: %v", err)
    case errors.Is(err, context.DeadlineExceeded):
        log.Printf("request deadline exceeded: %v", err)
    default:
        log.Printf("request failed: %v", err)
    }
    return
}

测试时可用 context.WithCancel 生成子 Context，先启动工作，再调用 cancel()，最后断言函数返回 context.Canceled。如果使用 WithTimeout，记得在函数结束时 defer cancel()，这样定时器和子 Context 的资源能及时释放。

最后复查三件事：Handler 是否从 r.Context() 开始；每个耗时下游是否接收同一个 Context；取消分支是否关闭响应体、停止重试并留下可检索的原因。三项都满足，才能确认“客户端离开后，服务端也会尽快停”。

相关问题

Handler 返回后还能继续使用 r.Context() 吗？

不应把它当作后台任务的生命周期。官方文档明确指出，ServeHTTP 返回时请求 Context 会被取消；需要脱离请求继续运行的任务，应设计独立生命周期、明确退出和错误处理。

context.WithTimeout 和客户端断开谁先生效？

谁先发生就由谁触发下游结束；业务层可以用 ctx.Err() 记录最终原因。父 Context 已经取消时，子 Context 不会把请求重新变成可用。

为什么后台任务不能直接复用请求 Context？

因为请求结束本来就会取消它。后台任务若需要独立运行，应创建独立的父 Context，并为任务设置自己的超时、取消入口和回收策略。

小结：Request.Context 负责传播取消信号，Handler、循环、HTTP 客户端和数据库调用负责协作执行。把信号传到最深的耗时点，再用错误分类和资源关闭做复查，才是客户端断开后的完整处理。