Go net/http 客户端断开后 Handler 的 Context 没结束怎么办

先区分两种现象：请求的 Context 没有收到取消，还是 Context 已取消但业务仍在执行。Go net/http 对入站请求约定了连接关闭、HTTP/2 请求取消和 ServeHTTP 返回时的取消行为；它不会强制终止业务 goroutine。若客户端与 Go 服务之间有代理，浏览器断开也不等于代理到后端的请求已经取消。

Go 官方地址：https://go.dev/。我更愿意先用一个只监听本机的服务把变量缩小，再分析部署链路。下面给出完整演示代码和读者可执行的方法；本文未运行这些命令，也不把预期日志当成真实故障证据。

这个小服务只回答“取消传到哪一层”

演示接口叫 /report，业务函数 buildReport 模拟五秒等待，不读请求体、不访问数据库、不额外启动 goroutine。Handler 将原始 r.Context() 直接传给业务，业务监听 Done 后返回。这样可以把“网络侧是否发出信号”和“业务是否消费信号”放在同一段小代码里讨论。

我不建议一开始就加入真实报表计算、数据库连接池和反向代理。它们当然重要，但会让一次未退出同时存在多个解释。先保留一个容易说明的请求边界，再逐项接回实际依赖。

准备单文件环境，避免混入旧中间件

在独立目录保存 main.go，使用可用的 Go 工具链；下面参考 Go 1.27.3 的 net/http 文档，不引入第三方路由器。选择未被占用的本地端口 8097，如需调整应同时修改客户端命令。监听地址限定为 127.0.0.1，不直接把演示服务暴露到公网。

尤其检查原服务中有没有用 context.Background() 覆盖请求上下文，或者使用 WithoutCancel 切断取消关系。那样业务看到的就不是原始请求的生命周期。演示代码故意不做这些替换。

把取消接收与业务退出放进同一个调用链

package main

import (
    "context"
    "errors"
    "fmt"
    "log"
    "net/http"
    "time"
)

// buildReport 模拟等待，取消时主动返回，不产生额外工作协程。
func buildReport(ctx context.Context) (string, error) {
    timer := time.NewTimer(5 * time.Second)
    defer timer.Stop()
    select {
    case 

这里最重要的是 buildReport 的 select，而不只是函数参数里出现 Context。若改成不可取消的长时间 Sleep，或者调用一个完全忽略 ctx 的阻塞函数，参数仍然存在，退出能力却丢了。CPU 密集工作也需要在合理粒度主动检查取消，不能指望 Context 抢占它。

日志同时记录业务错误和 request_err，有助于区分请求取消与业务自己的失败。这个例子没有子级超时；接回项目后若使用 WithTimeout，应另行记录原请求与子上下文的错误，防止把业务超时误认成客户端断开。

本地运行时看两个分支，不只看客户端报错

# 在新建的独立目录保存上面的 main.go，启动本机演示服务。
go run main.go

# 在另一个命令会话中正常等待，观察完整响应。
curl --http1.1 http://127.0.0.1:8097/report

# 再发起短超时请求，比较服务端业务退出日志。
curl --http1.1 --max-time 1 http://127.0.0.1:8097/report

第一条 go run 保持运行，后面的 curl 在另一个命令会话执行，不是要求在同一阻塞会话里继续输入。正常请求的预期是等待约五秒收到“报表已准备”。短超时请求会让客户端停止等待；若后端观察到了连接关闭，应进入取消分支，并记录业务退出。具体时刻取决于实际链路，不能预设精确毫秒数。

若客户端已经报错，而服务端一直等到计时器到期，先确认请求确实直连这个进程、没有系统代理或其他转发，然后观察原请求上下文。仅凭 curl 超时不能证明后端已经收到断连通知。测试结束后停止演示服务，避免把临时端口留成长期依赖。

接回代理和数据库时，我会逐层保留这条边界

代理在前端连接和后端请求之间建立了另一层边界。前端关闭是否终止上游请求，取决于具体代理及配置，本文不假设所有代理都有相同策略。因此应比较直连与经过代理的结果，再查看所用代理的官方说明，不能只调整 Go Handler。

接回数据库或下游 HTTP 请求时，也要传递同一个请求派生上下文，并使用支持 Context 的调用。它表达取消意图，但下游何时停止、驱动如何响应仍需按对应接口处理。不能把请求取消解读成数据库事务已经回滚，更不能据此宣布已发生的写操作被撤销。

用预期对照表决定下一步

要换成 CloseNotifier 吗？

新代码不应退回这个已经弃用的机制。官方建议使用 Request.Context；真正要明确的是上下文来源与业务是否响应，而不是换一个通知接口。

需要保证最长处理时间，能只等客户端断开吗？

不能。网络故障可能无法立即被服务端观察到。我会为业务设置单独的 WithTimeout 预算，记得调用 cancel 释放相关资源，并让业务继续协作退出；预算不会自动终止忽略上下文的函数。ReadHeaderTimeout 只限制读取请求头，不替代这项业务预算。

这个小项目适合定位请求级同步任务，不适合直接充当持久后台队列。对我来说，关键结论是把“通知已到达”和“工作已停止”分开记录，再沿着实际代理与依赖链处理，而不是看到客户端离开就假设所有工作已经结束。

参考：Request.Context 入站请求约定、Context 传播与取消接口、CloseNotifier 弃用说明。