Request上下文取消后服务端仍在写怎么办

会出现这种现象，通常不是 Request.Context 失效，而是把“收到取消信号”和“服务端立刻停止”混成了一件事。对于服务端请求，客户端连接关闭、HTTP/2 请求被取消，或 handler 返回时，r.Context() 会被取消；但 Go 不会强行杀掉正在运行的 goroutine。业务代码必须监听取消信号，下游调用也要接收这个 Context，同时把 ResponseWriter.Write 的错误当成退出条件。

官方资料：https://pkg.go.dev/net/http

最实用的处理方式是三层一起做：循环用 ctx.Done() 停止生产，写响应检查 Write 返回的错误，长时间或流式写入再用写期限限制阻塞。只检查其中一层，服务端仍可能继续消耗资源或卡在写入上。

先判断取消信号的责任边界

r.Context() 是请求范围的协作式控制器，不是线程终止器。下面的代码把取消信号传进一个可能耗时的函数；函数是否退出，取决于它有没有在等待点选择 ctx.Done()。

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

    // 把请求上下文传给业务函数，让客户端断开可以向下游传播。
    if err := writeReport(ctx, w); err != nil {
        // 客户端已离开时，通常只记录低级别日志，不再尝试写错误页。
        log.Printf("write report stopped: %v", err)
        return
    }
}

这里的关键不是在 handler 外面另建一个后台 goroutine，而是让每一个可能等待的环节都能收到同一个取消信号。若函数内部调用了不接受 Context 的阻塞 API，外层即使已经取消，也只能等该 API 返回。

让计算循环和下游调用真正监听 Context

流式响应最容易踩坑：生产者不断生成数据，写入者不断调用 Write，但两边都没有观察取消。客户端关闭后，循环仍可能继续查询数据库、计算和组装缓冲区。把取消分支放在生产前和写入前，可以尽早释放资源。

func writeReport(ctx context.Context, w io.Writer) error {
    for {
        // 在生产下一块数据前先看请求是否已经取消。
        select {
        case 

真实项目中，优先选择带 Context 参数的数据库、HTTP 客户端和队列 API。不要在取消后继续把任务交给一个没有生命周期约束的后台 goroutine，否则请求虽然结束，工作仍然会泄漏到请求之外。

写响应时检查 Write 返回值

检测到 ctx.Done() 仍不够。取消信号和底层写入错误不是同一个时刻发生的：客户端可能已经关闭连接，但服务端尚未观察到取消；也可能数据已经进入缓冲区，当前一次 Write 暂时成功。因此每次写入都要判断返回的字节数和错误。

func stream(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()
    flusher, canFlush := w.(http.Flusher)

    for i := 0; i 

不要把写入错误简单改成重试。对于已经关闭的客户端，重试只会重复占用 CPU、内存和网络；只有在协议明确允许、且错误确实是临时性的场景，才应设计有限次数的重试。

为长时间写入加上写期限

如果客户端还保持连接但读取很慢，写入可能因为背压而阻塞。请求上下文负责表达请求是否还值得继续，写期限负责限制一次响应写入可以等待多久，两者解决的是不同问题。Go 1.20 起可以通过 http.NewResponseController 设置写期限；不支持该能力的包装器会返回不支持错误。

func boundedStream(w http.ResponseWriter, r *http.Request) error {
    controller := http.NewResponseController(w)

    // 给响应写入设置上限，避免慢客户端让 handler 无限等待。
    if err := controller.SetWriteDeadline(time.Now().Add(10 * time.Second)); err != nil {
        // 某些 ResponseWriter 包装器不支持写期限，记录后仍可依赖 ctx 和 Write 错误。
        log.Printf("write deadline unavailable: %v", err)
    }

    for {
        select {
        case 

写期限不是取消通知，也不会替你停止上游计算。设置了期限后，仍要在业务循环里监听 ctx.Done()，并在 Write 返回错误时结束当前请求。

按三层防线排查仍在写的问题

排查时不要只盯着“上下文已经 canceled”这一行日志。正确的观察顺序是：取消信号有没有到达业务循环、下游操作有没有使用同一个 Context、响应写入有没有返回错误、写入是否可能被慢客户端卡住。

结论：把“停止工作”和“停止写入”分开处理

Request 上下文取消后服务端仍在写，最常见的根因是只接收了取消信号，却没有把它接入业务循环和下游调用。推荐的最小原则是：ctx.Done() 负责协作式停止，Write error 负责识别传输失败，write deadline 负责限制阻塞时间。三者组合后，客户端断开、网络错误和慢客户端才会落到清晰的退出路径上。

相关问题

• 客户端断开后，数据库查询会自动停止吗？只有把 r.Context() 传给支持 Context 的查询 API，取消才会传播。
• 收到 ctx.Err() 后还要写一个 JSON 错误响应吗？如果客户端已经断开，通常不应继续写；先记录请求标识和取消原因即可。
• http.Server.WriteTimeout 和 SetWriteDeadline 怎么选？前者是服务器级默认策略，后者适合对某个响应或特定阶段做更细粒度限制。