Go 1.8 移除 net/http.CloseNotifier 是因其易误用、语义模糊且与 HTTP/2 复用冲突；推荐改用 r.Context() 获取 context.Context，在客户端断开时自动取消。
net/http.CloseNotifier 在 Go 1.8 中已被移除，无法使用。
为什么 CloseNotifier 不再可用
Go 官方在 1.8 版本中彻底删除了 CloseNotifier 接口，原因是它容易被误用、语义模糊，且与 HTTP/2 的连接复用模型冲突。任何依赖它的代码在升级到 Go 1.8+ 后会编译失败，错误类似：undefined: http.CloseNotifier。
更关键的是，即使旧版本中它“看似工作”，实际也常因中间代理（如 Nginx、Cloudflare）、TLS 终止或 HTTP/2 升级而失效 —— 客户端断开后 Notify() 通道可能永不关闭。
替代方案：用 context.Context 配合 Request.Context()
Go 1.7 引入 Request.Context()，其返回的 context.Context 在客户端断开时自动取消（前提是底层 net.Conn 支持读超时且未被中间件劫持）。这是当前唯一推荐、标准且可靠的方式。
- 所有
http.Handler实现中，直接从r.Context()获取上下文 - 用
select监听ctx.Done()，而非监听已不存在的Notify()通道 - 注意：仅当 handler 正在执行且未返回时，
ctx.Done()才有意义；返回后 context 已被回收
示例：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func handler(w http.ResponseWriter, r *http.Request) {
ctx := r.Context()
done := ctx.Done()
// 启动一个可能耗时的操作
go func() {
select {
case <-done:
// 客户端断开，清理资源
log.Println("client disconnected")
case <-time.After(10 * time.Second):
// 正常完成
w.Write([]byte("done"))
}
}()
}哪些场景下 Context.Done() 仍不可靠
即使用了 Request.Context()，以下情况仍可能导致断开检测延迟或失效：
- Nginx 默认配置下不透传连接状态；需设置
proxy_ignore_client_abort off;并启用keepalive_requests - HTTP/2 连接复用时，单个流（stream）关闭不会触发整个 request context 取消（但 Go 的
http.Server在流关闭时仍会 cancel 对应 request context） - 客户端静默断连（如拔网线），TCP FIN 可能延迟到达，OS 层需等待 RST 或 keepalive 超时（默认几分钟）
- 使用
io.Copy或http.ServeFile等阻塞写操作时，context 取消不会中断写入 —— 必须配合可中断的写法（如带 context 的io.CopyN或自定义 writer）
如果必须做实时断连响应（如长轮询、SSE）
不能只靠 ctx.Done()，需主动探测：
- 对长连接启用
http.Server.ReadTimeout和WriteTimeout，并设为较短值（如 30s） - 定期向客户端写入心跳（如 SSE 的
:注释行），并在写失败时捕获write: broken pipe或use of closed network connection - 避免使用
ResponseWriter的原始Write，改用封装了 error 检查的工具函数
例如判断写失败：
if _, err := w.Write(data); err != nil {
if errors.Is(err, net.ErrClosed) || strings.Contains(err.Error(), "broken pipe") {
log.Println("client gone")
return
}
}真正可靠的断连感知永远依赖 TCP 层反馈和主动探测，不是某个接口的有无。别再找 CloseNotifier 的替代包 —— 那些只是对已废弃行为的模拟，掩盖了网络本质。
