WebSocket连接存活需主动心跳探活而非依赖onclose/onerror，Go中须设ReadDeadline并用SetPongHandler重置，sync.Map存连接时须在CloseHandler清理且原子计数，查在线数应直接读atomic.Int64而非Range。
WebSocket 连接状态不能只靠 onclose 或 onerror 判断，那些事件在 NAT 超时、代理静默断连、移动网络切换时根本不会触发，你看到的“在线人数”很可能全是僵尸连接。
为什么 conn.ReadMessage() 阻塞不等于连接还活着
Go 的 gorilla/websocket 默认启用 TCP Keep-Alive，但系统级默认间隔是 2 小时，远超业务容忍范围。调用 conn.ReadMessage() 会阻塞等待数据，但底层 TCP 连接可能早已被中间设备（如 AWS ALB、Nginx）因空闲超时（常见 60–300 秒）悄悄关闭，而 Go runtime 不会立刻感知 —— 直到下次写操作才报 write: broken pipe，或读超时后返回 io.EOF。
实操建议：
- 必须显式设置
conn.SetReadDeadline()，每次读前都更新，超时时间建议设为心跳间隔的 1.5 倍（例如心跳 30s，读超时设 45s） - 不要依赖
ReadMessage()的阻塞来“守着连接”，它不提供存活信号 - 若用
conn.SetPongHandler()，记得在 handler 里重置读 deadline，否则下一次读会立即超时
sync.Map 存连接 + atomic.Int64 统计在线数的坑
直接用 map[string]*websocket.Conn 并发读写会 panic；用 sync.Mutex 包裹虽安全，但在高并发查在线数（QPS 上万）时锁争用严重。用 sync.Map 是更优解，但容易漏掉三个关键点：
-
clients.Store()必须在握手成功后、任何消息收发前执行，否则重连时旧连接残留 -
conn.SetCloseHandler()是清理唯一可靠入口，defer conn.Close()只能兜底正常流程，异常断连时它根本不会执行 - 在线计数器必须用
atomic.AddInt64(&onlineCount, -1)在Delete()之后调用，顺序反了会导致负数 —— 而且这个减法不能放在 CloseHandler 里做耗时操作（比如写 DB），它运行在协议 goroutine 中，卡住会影响所有连接的心跳响应
心跳帧（Ping/Pong）该谁发、怎么发才不丢
浏览器原生 WebSocket API 不暴露 Ping 帧发送能力，ws.send('ping') 是应用层模拟，服务端需额外解析；而 Go 的 gorilla/websocket 支持原生 Ping，客户端无需代码改动。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
实操建议：
- 服务端开启自动 Pong：
conn.SetPongHandler(func(string) error { atomic.StoreInt64(&lastPong, time.Now().Unix()); return nil }) - 客户端不用发 Ping —— 由服务端主动发（
conn.WriteControl(websocket.PingMessage, nil, time.Now().Add(10*time.Second))），避免客户端实现不一致 - 服务端每 30 秒发一次 Ping，同时维护一个
lastPong int64时间戳，检查间隔设为 90 秒：若time.Now().Unix() - lastPong > 90，就认为连接已死，主动conn.Close()并清理sync.Map - 别在前端用
setInterval(() => ws.send('ping'), 30000)，移动端后台标签页会节流定时器，心跳直接失效
查在线人数接口为什么不能 clients.Range()
sync.Map.Range() 每次调用都要遍历全部键值对，哪怕你只想要一个数字。当在线用户达 10 万时，单次调用 CPU 占用明显，QPS 上千就会拖慢整个服务。
真正轻量的做法只有一个：独立维护 var onlineCount int64，上线时 atomic.AddInt64(&onlineCount, 1)，下线时 atomic.AddInt64(&onlineCount, -1)，查询接口直接 return atomic.LoadInt64(&onlineCount) —— 这是纳秒级、零分配的操作。
注意：这个值不是强一致的，但在线人数本就不需要毫秒级精确；你真正该花精力的，是确保每个连接的生命周期都被 SetCloseHandler 和心跳探活双重覆盖，而不是纠结 Range 返回的是不是“刚刚好”的快照。
