gorilla/websocket是Golang中WebSocket通信的首选，但需规避并发map读写、读写goroutine耦合、Upgrader配置缺失、心跳与超时机制缺位等关键陷阱。
gorilla/websocket 是 Golang 中实现 WebSocket 通信最稳定、最常用的选择，不是“能用”，而是“该用”——它把协议细节封装得足够干净，又留出足够控制权。但直接照抄示例代码上线，90% 会掉进连接泄漏、并发 panic 或消息丢失的坑里。
为什么不能直接用 map[*websocket.Conn]bool 管理连接
这是新手最常写的代码，也是线上崩溃第一大诱因：Go 的原生 map 不支持并发读写。一旦两个 goroutine 同时调用 delete() 或遍历，程序立即 panic：fatal error: concurrent map read and map write。
- 正确做法是只在**单个 goroutine（如 hub）中增删**，其他地方通过 channel 发送注册/注销指令
- 或改用
sync.Map，但它不支持遍历，广播时仍需额外结构来存活跃连接列表 - 更推荐组合方案：用
sync.RWMutex+ 普通 map，读多写少场景下性能和可读性更平衡
readPump 和 writePump 必须拆开，且不能共用 channel
一个连接如果只用一个 goroutine 处理读+写，遇到数据库查询、HTTP 调用等阻塞操作，整个连接就卡死——既收不到新消息，也发不出响应，用户感知就是“突然断连”。
-
readPump：只负责conn.ReadMessage()→ 解析 → 发到broadcastchannel -
writePump：从每个 client 自己的sendchannel 取消息 →conn.WriteMessage() - 关键点：
sendchannel 必须 per-client，不能所有连接共用一个；否则私聊、房间隔离、优先级推送全失效
Upgrader 的三个配置项，漏一个就埋雷
很多服务跑几天后开始报错 use of closed network connection 或大量 goroutine 泄漏，往往就差这三行：
立即学习“go语言免费学习笔记（深入）”；
-
CheckOrigin：开发阶段设为func(r *http.Request) bool { return true }没问题，但上线必须校验r.Header.Get("Origin")，否则任意网站都能连你服务，成 DDoS 跳板 -
ReadBufferSize/WriteBufferSize：默认 4096 字节，若业务消息平均 6KB，每次都要分片+多次系统调用。建议按 P99 消息大小设为8192或16384 -
EnableCompression: true：对 JSON 文本压缩率超 60%，但会吃 CPU；内网或二进制数据传输建议关掉
心跳不是可选项，而是连接生命周期管理的起点
浏览器关闭标签页、手机切后台、NAT 超时……这些都不会触发 websocket.CloseMessage，服务端若不主动探测，连接就挂着不释放，fd 和内存持续增长。
- 服务端调用
conn.SetPingHandler()（默认已注册），再起 goroutine 定期conn.WriteMessage(websocket.PingMessage, nil) - 必须配
SetReadDeadline：每次ReadMessage前设置，比如conn.SetReadDeadline(time.Now().Add(30 * time.Second)) - 收到
io.EOF或*websocket.CloseError时，立刻delete连接、close(send)、conn.Close()—— 缺一不可
真正难的从来不是“连上 WebSocket”，而是让成百上千个长连接在各种异常网络下稳住状态、不丢消息、不爆内存。这些细节不写进代码里，压测一上来就露馅。
