准确统计websocket连接数需服务端主动维护原子计数器：在connection事件增、close/error事件减，避免依赖wss.clients.size；配合心跳超时踢出，并通过process.nexttick安全暴露http接口。
WebSocket服务端如何准确统计当前连接数
关键在于不依赖客户端上报，而是从服务端连接生命周期里主动计数。Node.js 的 ws 库没有内置连接总数接口，必须手动维护一个全局计数器或 Map。
常见错误是把 connection 事件和 close 事件的回调写在不同作用域里，导致 close 里无法访问计数变量，或者用 setInterval 定时遍历 wss.clients——这在高并发下不准且开销大（wss.clients 是 Set，遍历时可能触发 GC 暂停）。
正确做法是：在 WebSocketServer 实例创建后，用闭包或模块级变量维护一个原子计数器，并确保增减操作成对、同步：
let connectionCount = 0;
const wss = new WebSocketServer({ port: 8080 });
wss.on('connection', (ws) => {
connectionCount++;
ws.on('close', () => {
connectionCount--;
});
ws.on('error', () => {
connectionCount--; // 防止异常断连漏减
});
});
为什么不能直接用 wss.clients.size 获取实时人数
wss.clients 确实是当前所有活跃连接的 Set，但直接读取它有三个硬伤：
- 不是线程安全：在 Node.js 单线程模型下看似安全，但
ws内部对clients的增删可能发生在异步 tick 中，size读取瞬间可能已过期 - 包含半关闭连接：某些网络中断场景下，socket 已不可写但未触发
close事件，wss.clients仍保留该实例，造成虚高 - 无心跳校验：如果客户端静默掉线（如拔网线），服务端不会立刻感知，
wss.clients不会自动清理
所以生产环境必须配合心跳机制（ping/pong）+ 超时踢出逻辑，再结合计数器，才能接近真实在线数。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
暴露连接数给 HTTP 接口时要注意什么
用 Express 或原生 http.Server 提供一个 /api/ws-count 接口很简单，但容易忽略两点：
- 不要在响应中直接返回
connectionCount变量——它可能被多个事件回调并发修改，需加锁；最轻量方案是用process.nextTick包裹读取，确保在当前 tick 结束前值稳定 - 避免暴露敏感信息：别把
wss.clients整个 dump 出来（含 IP、协议头等），只返回数字或简单对象 - 加缓存头防刷：高频轮询下，可设
Cache-Control: public, max-age=1，让前端或 CDN 缓存 1 秒
示例（Express）：
app.get('/api/ws-count', (req, res) => {
process.nextTick(() => {
res.json({ count: connectionCount });
});
});
前端实时刷新在线人数的合理频率和降级策略
前端每秒发一次请求查人数？没必要，也浪费资源。真实场景下，用户对“实时”容忍度很高——2～5 秒延迟完全不可感知。
更关键的是降级：当 HTTP 接口失败（如超时、503），不要停止轮询或报错，应退回到指数退避（如 2s → 4s → 8s），并记录到 console.warn；如果连续失败超过 5 次，可显示 “人数统计暂不可用”，但保持 WebSocket 自身连接不受影响。
另外，别在 WebSocket.onopen 里立即触发人数查询——此时服务端可能还没完成 connection 事件回调，计数器尚未 +1，会导致刚连上就看到比实际少 1 的数字。
