buffalo框架无法主动感知客户端断开连接，需依赖http.request.context().done()监听取消信号；所有阻塞操作应传入该上下文并定期检查，避免资源浪费。
Buffalo 框架如何感知客户端断开连接
Buffalo 默认不会主动检测或响应客户端提前关闭连接（如用户刷新、网络中断、浏览器关闭标签页），它基于 net/http 运行，而 Go 标准库本身不暴露“连接已断”事件——直到你尝试向响应体写数据时，write: broken pipe 或 write: connection reset by peer 才会作为 error 返回。
在 Handler 中检查连接是否有效
Buffalo 的 buffalo.Context 封装了 http.ResponseWriter 和 *http.Request，但没提供开箱即用的连接状态检查方法。你需要手动调用底层 ResponseWriter 的 Hijack() 或依赖 Request.Context().Done() —— 后者才是推荐路径，因为从 Go 1.8 起，http.Request.Context() 会在客户端断连时自动 cancel。
-
ctx := c.Request().Context()是唯一可靠入口； - 所有阻塞操作（如数据库查询、HTTP 调用、
time.Sleep）都应接受该ctx并传给下游（例如db.QueryContext(ctx, ...)）； - 若你在 Handler 里做了长时间轮询或流式响应（如 SSE），必须定期检查
select { case ； - Buffalo 自身中间件（如日志、session）一般不监听
ctx.Done()，所以取消逻辑得你自己加。
为什么 ctx.Err() == context.Canceled 不一定代表客户端断开
这个错误可能来自多种原因：超时中间件触发、手动调用 context.CancelFunc、甚至测试中 mock 请求主动 cancel。仅凭 ctx.Err() 无法 100% 区分是客户端断开还是服务端主动终止。真正能佐证的是后续对 ResponseWriter.Write() 的调用返回非 nil error，且 error message 包含 broken pipe 或 connection reset。
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 不要在
defer里仅靠ctx.Err()做资源清理判断； - 如果业务强依赖“用户确实走了”，建议结合心跳 + 客户端主动发 disconnect 事件更稳妥；
- Buffalo 的 WebSocket 支持（通过
github.com/gorilla/websocket）有明确的conn.Close()和conn.SetReadDeadline()机制，比 HTTP 更可控。
实际写法示例：带 cancel 检查的长耗时 Handler
func SlowHandler(c buffalo.Context) error {
ctx := c.Request().Context()
// 假设这里要查一个可能慢的聚合接口
result, err := slowAPI.CallContext(ctx, "user-stats")
if err != nil {
if errors.Is(err, context.Canceled) || errors.Is(err, context.DeadlineExceeded) {
// 此处可记录为“请求被中断”，但不要返回 500
return nil // 或 c.Error(499, errors.New("client disconnected"))
}
return errors.WithStack(err)
}
return c.Render(200, r.JSON(result))
}
注意：返回 499 Client Closed Request 是 Nginx 常用状态码，但 Go net/http 默认不支持，需手动写入： c.Response().WriteHeader(499)，且不能再调用 c.Render。
真正难处理的不是“知道断了”，而是“断了之后还在往 DB/Redis/下游发请求”。这类问题不会报错，只会拖慢整个 goroutine，最终堆积导致 GOMAXPROCS 耗尽。务必让所有 IO 调用链都接收并传递 context。
