17370845950

gorilla/websocket是Golang中WebSocket通信的首选，但需规避并发map读写、读写goroutine耦合、Upgrader配置缺失、心跳与超时机制缺位等关键陷阱。

gorilla/websocket 是 Golang 中实现 We

bSocket 通信最稳定、最常用的选择，不是“能用”，而是“该用”——它把协议细节封装得足够干净，又留出足够控制权。但直接照抄示例代码上线，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() → 解析 → 发到 broadcast channel
• writePump：从每个 client 自己的 send channel 取消息 → conn.WriteMessage()
• 关键点：send channel 必须 per-client，不能所有连接共用一个；否则私聊、房间隔离、优先级推送全失效

Upgrader 的三个配置项，漏一个就埋雷

很多服务跑几天后开始报错 use of closed network connection 或大量 goroutine 泄漏，往往就差这三行：

• 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”，而是让成百上千个长连接在各种异常网络下稳住状态、不丢消息、不爆内存。这些细节不写进代码里，压测一上来就露馅。