gorilla/websocket 更靠谱是因为 net/http 无原生 WebSocket 支持，硬升级易卡握手或丢帧；而 gorilla 封装了 Upgrade、心跳、分片、并发读写保护等关键逻辑。
gorilla/websocket 为什么比 net/http 自带的更靠谱
Go 标准库 net/http 没有原生 WebSocket 支持，硬用 http.ResponseWriter 升级连接容易卡在握手或丢帧。真正能上线的聊天室基本都依赖 gorilla/websocket——它把 Upgrade、ping/pong 心跳、消息分片、并发读写保护这些脏活全包了。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 别自己实现
Upgrade，直接用upgrader.Upgrade()，它会自动处理Sec-WebSocket-Key和 101 响应 -
Upgrader.CheckOrigin默认拒绝所有跨域请求，开发时设为func(r *http.Request) bool { return true }，上线必须收紧 - 每个连接要配独立的
*websocket.Conn实例，不能多个 goroutine 并发调WriteMessage，否则 panic 报concurrent write to websocket connection
怎么安全地广播消息给所有在线用户
“群发”不是遍历 map 然后挨个 WriteMessage 就完事。真实场景下，某个用户网络抖动或已断开，但连接对象还没被回收，强行写会导致 write tcp: use of closed network connection 错误，还可能拖垮整个广播逻辑。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Map存连接（key 是用户 ID 或随机 token，value 是*websocket.Conn），避免 map 并发读写冲突 - 发消息前先调
conn.WriteMessage，捕获websocket.IsCloseError(err)或io.ErrClosedPipe，出错就从 map 里删掉这个 conn - 广播用单独 goroutine 异步做，主逻辑只负责往一个
chan []byte推消息，避免阻塞接收协程
客户端断连后，服务端怎么及时清理资源
浏览器关标签、手机切后台、WiFi 切 4G……这些都不会触发 onclose 立即上报，服务端靠心跳超时才能感知。默认 gorilla/websocket 的 ping/pong 间隔是 0，等于不发心跳，连接会一直挂着占内存和文件描述符。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 初始化
Upgrader时设置upgrader.PingTimeout = 10 * time.Second，并启用conn.SetPingHandler处理客户端 pong - 每个连接启动一个
time.AfterFunc定时器，收到 ping 就重置，超时就conn.Close()并从连接池删除 - 别依赖
defer conn.Close()—— 如果连接卡在ReadMessage，这个 defer 根本不会执行
如何让消息不丢、不乱序、不重复
WebSocket 协议本身不保证应用层消息顺序和可靠性。TCP 层有序，但 Go 的 WriteMessage 是异步刷缓冲区的，如果两个 goroutine 同时写，实际发出的帧可能交错；而客户端重连后，服务端若没做消息回溯，就会漏掉离线期间的消息。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个连接只启一个写协程，所有消息统一走
chan []byte，由它串行调WriteMessage - 给每条消息加单调递增的
msg_id，客户端按 ID 去重+排序（适合小规模聊天室） - 真要支持离线消息，得搭配 Redis 或本地 LRU cache，按用户 ID 存最近 N 条，重连后主动拉取，而不是靠 WebSocket 自身机制
最麻烦的从来不是连上，而是连上之后谁在什么时候以什么顺序收到了什么——协议不管的事，就得自己补。
