responsewriter 无法直接检测客户端断开，需通过 write/flush 返回的 broken pipe 或 connection reset 错误判断，且应优先使用 errors.is(err, syscall.epipe) 检测；context.done() 不可靠，存在延迟。
如何用 ResponseWriter 检测客户端已断开
Go 的 http.ResponseWriter 实际上是 http.responseWriter 的接口抽象，它不直接暴露连接状态，但底层实现了 Hijacker、Flusher 和 CloseNotify（已弃用）等能力。Gin 中最可靠的方式是检查 Write 或 Flush 是否返回 broken pipe 或 connection reset by peer 错误。
注意：不要依赖 c.Writer.(http.CloseNotifier) —— 该接口在 Go 1.8+ 已被移除，且 Gin 从 v1.9 起完全不支持。
- 在流式响应（如 SSE、大文件下载、长轮询）中，每次
c.Stream()或c.Writer.Write()后应检查错误 - 调用
c.Writer.Flush()后立即检查是否出错，这是发现断连的最早窗口之一 - 错误类型通常为
*net.OpError，需用errors.Is(err, syscall.EPIPE)或strings.Contains(err.Error(), "broken pipe")判定
context.Context 的 Done() 是否可靠？
HTTP handler 的 c.Request.Context().Done() 在客户端断开后**不一定立刻关闭**——它依赖底层 TCP FIN 包被内核接收并通知到 Go runtime，存在延迟（尤其在 NAT、代理、负载均衡后），有时长达数秒甚至更久。
因此不能单靠 select { case 做实时断连响应。
- 它适合做「最终兜底」，比如超时清理或 defer 关闭资源，但不适合作为主动检测手段
- 若你用
time.AfterFunc或time.Ticker配合ctx.Done()，务必加if ctx.Err() != nil双重校验 - Gin 的
c.Abort()不会中断正在执行的 goroutine，必须自己控制循环退出条件
WebSocket 场景下如何及时感知断开
Gin 本身不处理 WebSocket 升级逻辑，需手动调用 upgrader.Upgrade()。断开检测必须基于 *websocket.Conn 的读写行为，而非 HTTP 上下文。
- 调用
conn.ReadMessage()时若返回websocket.CloseMessage或io.EOF，说明客户端发起标准关闭 - 若返回
websocket.ErrCloseSent或网络类错误（如net.ErrClosed），大概率是异常断连 - 务必设置
conn.SetReadDeadline()和conn.SetWriteDeadline()，否则心跳超时无法触发中断 - 不要忽略
conn.Close()的返回值 —— 它可能因底层连接已关闭而报websocket: close sent
常见误判与性能陷阱
高频轮询或流式接口中，把网络抖动当成断连会导致过早终止响应；反过来，漏判又会造成 goroutine 泄漏和资源堆积。
- 避免每写 1 字节都检查错误 —— 合理批次写入（如 4KB~64KB）再
Flush并校验，平衡实时性与开销 - 不要在
for range c.Stream(...)循环里无条件time.Sleep，必须把ctx.Done()和写错误同时纳入 select - 使用
net/http/pprof观察goroutine数量突增，常是断连未清理导致的 goroutine 泄漏 - Kubernetes 中，Ingress 或 Service 的 connection idle timeout（如 30s）可能比你的代码逻辑更早切断连接，需对齐配置
