gorilla/websocket比标准库更稳，因其封装了握手、ping/pong、帧解析和并发读写保护；需注意子协议匹配、单goroutine写、服务端主动心跳、nginx升级头配置及连接生命周期管理。
用 gorilla/websocket 建连接比标准库更稳
Go 标准库没有原生 WebSocket 支持，net/http 只能靠手动升级连接，容易漏掉 Sec-WebSocket-Key 校验或响应头拼写错误（比如写成 Sec-Websocket-Accept 就会静默失败）。gorilla/websocket 封装了握手、ping/pong、消息帧解析和并发读写保护，上线前少踩一半坑。
实操建议：
- 用
upgrader.CheckOrigin = func(r *http.Request) bool { return true }临时绕过跨域限制，但上线前必须改成白名单校验，否则任意站点都能连你的 ws -
upgrader.Subprotocols要和前端new WebSocket(url, ['json'])的子协议严格一致，不匹配会导致连接立即关闭且无明确错误提示 - 每个连接必须启动独立 goroutine 处理
ReadMessage，否则阻塞会卡住整个连接；同时用conn.SetReadDeadline防呆，避免客户端断连后连接长期滞留
conn.WriteMessage 不能并发调用
WebSocket 连接对象不是线程安全的——WriteMessage 内部会序列化帧并写入底层网络连接，如果多个 goroutine 同时调用，大概率触发 write tcp: use of closed network connection 或消息错乱（比如 A 用户发的消息被 B 用户收到）。
常见错误现象：用户一多就频繁断连，日志里反复出现 websocket: write deadline exceeded，其实根本原因是写冲突导致连接被异常关闭。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 为每个
*websocket.Conn绑定一个带缓冲的chan []byte，所有写请求都发到这个 channel，再由单个 goroutine 顺序消费并调用WriteMessage - 不要用
sync.Mutex包裹WriteMessage——锁粒度太粗，高并发下会成为瓶颈；channel 方式天然解耦且可控 - 发送前检查
conn.CloseChan()是否已关闭，避免往已关闭连接发消息引发 panic
心跳保活必须服务端主动发 ping
浏览器 WebSocket 在空闲 30–60 秒后可能被中间代理（如 Nginx、CDN）静默断开，仅靠客户端发 ping 不够。Nginx 默认 proxy_read_timeout 是 60 秒，若服务端 60 秒内没发任何数据，连接会被直接 kill，且不通知客户端。
使用场景：用户切到其他标签页、手机锁屏、网络短暂抖动后重连失败，往往就是心跳缺失导致的“假在线”。
实操建议：
- 在
conn.SetPingHandler里只做conn.SetPongHandler的配对响应，真正的心跳驱动要靠time.Ticker每 25 秒调一次conn.WriteMessage(websocket.PingMessage, nil) - 不要依赖
SetPongHandler做业务逻辑——它只保证连接存活，不反映客户端是否真在线；需配合最后通信时间戳 + 定期扫描清理超时连接 - Nginx 配置必须加：
proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection "upgrade";，否则 upgrade 请求被转成普通 HTTP，后续 ping 全部失败
消息广播性能瓶颈在锁竞争，不是 JSON 序列化
聊天室最常写的 for _, c := range clients { c.Write(...) } 看似简单，实际在 100+ 连接时，每次广播都要遍历、加锁、逐个写，CPU 很快被 goroutine 调度和 mutex 竞争吃满，而不是卡在 json.Marshal 上。
参数差异：gorilla/websocket 的 WriteJSON 内部只是封装了 json.Marshal + WriteMessage，和手动 marshal 后 WriteMessage 性能几乎无差别。
实操建议：
- 把广播消息提前序列化成
[]byte，避免每次广播重复 Marshal；用sync.Pool复用bytes.Buffer减少小对象分配 - 客户端列表改用
map[uint64]*Client+sync.RWMutex，读多写少场景下RLock开销远低于全量互斥锁 - 如果房间规模持续增长，考虑按用户 ID 哈希分片，把大广播拆成多个小广播，避免单次锁持有时间过长
真正难处理的是连接生命周期管理：用户刷新页面、网络闪断、恶意短连，这些场景下连接清理不及时，会导致内存缓慢上涨、goroutine 泄漏。别只盯着消息怎么发得快，先确保每个 defer conn.Close() 都落在正确位置，且 Close 前清掉了所有 channel 和 timer。
