Buffalo 框架不内置 WebSocket 支持，须绕过中间件链用 gorilla/websocket 手动升级连接；路由需直连 handler，Upgrader 必须显式配置 CheckOrigin、Subprotocols、缓冲区及压缩；每个连接需独立 writePump goroutine 保障线程安全。
Buffalo 框架本身不内置 WebSocket 支持，所有 WebSocket 逻辑必须绕过 Buffalo 的中间件链、手动用 gorilla/websocket 实现；否则连接会在 Upgrade 阶段静默失败。
Buffalo 路由必须跳过中间件直接升级连接
Buffalo 的 Context 包装了 ResponseWriter，而 WebSocket 协议升级要求响应头**一字不差**：必须包含 Upgrade: websocket、Connection: Upgrade 和正确的 Sec-WebSocket-Accept。任何中间件（包括日志、CORS、gzip）一旦调用 WriteHeader() 或写入 body，就会提前锁定 header，导致浏览器控制台只显示 WebSocket connection to 'ws://' failed，无其他提示。
- 在
routes.go中注册路由时，用app.GET("/ws", websocketHandler)，但确保该 handler 不经过app.Use(...)链 - handler 内部必须直接调用
upgrader.Upgrade(c.Response().Writer, c.Request(), nil)，禁止使用c.Response().WriteHeader()或c.Render() - 若需跨域，把
CheckOrigin设为白名单函数，不要依赖中间件注入Access-Control-Allow-Origin
gorilla/websocket Upgrader 必须显式配置关键字段
Buffalo 不封装 websocket.Upgrader，你得自己初始化。漏掉任意一项，高并发下会出现连接被 CDN 拦截、心跳失效、或 buffer 频繁分配拖慢吞吐。
-
CheckOrigin必须校验r.Header.Get("Origin")，禁止设为func(r *http.Request) bool { return true }（否则易被 DDoS 扫描耗尽连接数） -
Subprotocols显式声明，例如[]string{"chat-v1"}；某些反向代理（如 Cloudflare）会静默丢弃无子协议的 Upgrade 请求 -
ReadBufferSize和WriteBufferSize建议设为65536，避免小 buffer 在消息 burst 时触发频繁内存分配 -
EnableCompression: true可启用，但仅对文本消息生效，且需客户端支持permessage-deflate
每个连接必须配独立 writePump goroutine
*websocket.Conn 不是线程安全的。Buffalo 的 handler 返回后，若多个 goroutine（比如广播逻辑 + 心跳 goroutine）同时调 conn.WriteMessage()，大概率触发 write tcp: use of closed network connection 或消息错发。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 为每个连接启动一个专属
writePumpgoroutine，从chan []byte读取消息并串行调用conn.WriteMessage() - channel 缓冲区大小建议设为
16–64：过小易阻塞发送方，过大则内存堆积 - 广播前检查
client.send是否已关闭（select { case _, ok := ），避免 panic - 永远不要在广播循环里直接调
conn.WriteMessage()——即使加了 mutex，也无法解决 TCP 写缓冲区满时的阻塞问题
Nginx 反向代理下必须显式设置超时与 Upgrade 头
Buffalo 服务常部署在 Nginx 后，而 Nginx 默认不透传 WebSocket 升级头，且 proxy_read_timeout 默认 60 秒，会导致连接被静默断开。
- Nginx 配置中必须显式添加：
proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection "upgrade"; -
proxy_read_timeout至少设为75秒（建议 90），并与服务端心跳间隔（如 30 秒 ping）和SetReadDeadline策略对齐 - 服务端需主动发
websocket.PingMessage，并在SetPongHandler中重置SetReadDeadline，否则 Go 侧仍维持“活着”的假象 - 前端 new WebSocket 时若指定了子协议（如
new WebSocket(url, ["chat-v1"])），服务端Subprotocols必须严格匹配，否则连接立即关闭且无明确错误
最易被忽略的是：Buffalo 的 Context 生命周期与 WebSocket 连接生命周期完全不重合——handler 执行完就返回，但连接可能持续数小时。所有状态管理（连接注册、心跳、广播队列、超时控制）都必须脱离 Buffalo 上下文，用独立 goroutine + channel + sync.Map 实现，否则一压测就泄漏、断连、panic。
