直接用gorilla/websocket配合Gin可实现WebSocket双向通信，但生产环境80%问题源于连接管理、错误处理和鉴权；gin-gonic/websocket已弃用，不支持CloseMessage等关键帧，官方推荐gorilla/websocket，其Upgrader提供CheckOrigin、Subprotocols等精细控制，且*websocket.Conn支持SetReadDeadline等防呆机制，升级后须在成功校验err后立即defer conn.Close()并统一closeConn封装，连接池需用sync.Map+状态字段而非裸指针，广播前须设WriteDeadline，断连时须关闭send channel，集群广播、重连、消息补发、登出清理等才是真实难点。
直接用 gorilla/websocket 配合 Gin 路由就能跑通 WebSocket 双向通信，但生产环境里 80% 的问题出在连接管理、错误处理和鉴权环节，不是协议本身不会用。
为什么不能直接用 gin-gonic/websocket？
这个包早已被官方弃用（2023 年起不再维护），文档缺失、不支持 websocket.CloseMessage 等关键控制帧，且无法自定义握手头。实际项目中必须切换到 gorilla/websocket —— 它是 Go 生态事实标准，Gin 官方示例也默认推荐它。
-
gorilla/websocket提供完整的Upgrader控制，比如CheckOrigin、Subprotocols、HandshakeTimeout - 它返回的
*websocket.Conn支持细粒度读写控制，例如SetReadDeadline防呆连接 - Gin 的
Context仅用于升级阶段；升级后必须脱离 Gin 生命周期，否则会因中间件超时或响应体写入导致 panic
upgrader.Upgrade 后必须立即 defer conn.Close() 吗？
必须，但位置很关键：要放在升级成功之后、进入消息循环之前。漏掉或放错位置会导致连接泄漏，尤其在高并发场景下，连接数会持续上涨直到 OOM。
- 错误写法：
defer conn.Close()放在if err != nil判断前 → 升级失败时也会执行，panic - 正确顺序：先检查
err，再defer conn.Close()，再启动读/写协程 - 更稳妥的做法是封装
closeConn函数，在所有退出路径（包括读写 error、主动断开）统一调用
如何让多个 HTTP handler 共享同一个 WebSocket 连接池？
不能靠全局 map 存 *websocket.Conn，因为连接对象不可并发安全读写，且没有生命周期感知。必须用带同步机制的结构体封装，比如 sync.Map + 连接状态字段。
- 每个连接应绑定唯一
userID（从 JWT 或 cookie 解析），而不是用*websocket.Conn做 key —— 它不支持比较，且 GC 后地址可能复用 - 广播消息时，遍历前先
conn.WriteMessage前加conn.SetWriteDeadline，避免某个慢连接阻塞整个广播 - 连接断开时，除了从 map 删除，还要显式关闭其专属的
sendchannel，防止 goroutine 泄漏
真正难的从来不是“连上”，而是连接断了怎么重连、消息丢了怎么补、用户登出时连接没及时清理、集群环境下广播怎么跨实例——这些细节不处理，上线三天就报警。
