gorilla/websocket 是首选，因标准库无原生 WebSocket 支持，需手动实现帧解析、ping/pong 等 RFC 6455 逻辑，而 gorilla 已完整验证且持续维护，避免 handshake 失败、掩码校验错误等问题。
为什么 gorilla/websocket 是首选而不是标准库
Go 标准库没有原生 WebSocket 支持，net/http 只能处理 HTTP 协议握手阶段，后续帧解析、ping/pong、连接状态管理全得自己写。直接上手容易卡在 websocket: bad handshake 或连接秒断——因为缺少正确升级头、掩码校验、控制帧响应等逻辑。
用 gorilla/websocket 能绕过这些底层坑，它已通过 RFC 6455 全流程验证，且活跃维护。安装只需：
go get github.com/gorilla/websocket
注意：别用已归档的 golang.org/x/net/websocket，它不支持现代浏览器（如 Chrome 90+）的掩码强制策略，会报 websocket: client sent invalid frame。
如何正确处理 WebSocket 连接升级和并发读写
HTTP handler 中不能直接 Write 响应体后再升级，否则会触发 http: multiple response.WriteHeader calls。必须用 Upgrader.Upgrade() 一次性完成握手并获取 *websocket.Conn。
立即学习“go语言免费学习笔记（深入）”；
Upgrader 需显式配置，尤其跨域场景：
var upgrader = websocket.Upgrader{
CheckOrigin: func(r *http.Request) bool {
return true // 生产环境应校验 Origin
},
}每个连接需分离读写 goroutine，否则 ReadMessage() 和 WriteMessage() 会互相阻塞（WebSocket 协议要求帧有序）。典型结构：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 主 goroutine 负责
ReadMessage()，解析后发到 channel - 单独 goroutine 从 channel 拉消息，调用
WriteMessage() - 用
conn.SetReadDeadline()防客户端假死，避免 goroutine 泄漏
如何安全广播消息而不 panic
直接遍历连接列表并发写入会触发 concurrent write to websocket connection panic——*websocket.Conn 的写操作不是 goroutine-safe 的。
两种可靠做法：
- 为每个连接配一个专属写 channel（如
chan []byte），写 goroutine 独占消费，广播时向所有 channel 发送副本 - 用
conn.WriteJSON()替代WriteMessage()，它内部加了锁，但仅适合小消息（频繁 JSON 序列化有开销）
别用全局 map 存连接然后 for-range 写，没加锁必崩；也别在 HTTP handler 里直接 conn.WriteMessage()，此时连接可能已被另一 goroutine 关闭。
生产环境必须关掉的默认行为
gorilla/websocket 默认启用 PingHandler 和 PongHandler，但若没设读超时，客户端不发 ping 时连接永不关闭，导致内存泄漏。
必须设置：
-
conn.SetReadDeadline(time.Now().Add(30 * time.Second))在每次ReadMessage()前 -
upgrader.HandshakeTimeout = 5 * time.Second防握手耗时过长 -
upgrader.WriteBufferSize = 1024控制发送缓冲区，避免大消息阻塞
另外，WriteMessage() 失败时不会自动重连，要检查返回 error 并显式 conn.Close()，否则 fd 会一直占用。
