websocket实时用户状态检测需协同连接层、状态层、存储层与前端层：连接层用onopen/onclose作强信号但不唯一依赖；状态层结合30秒心跳与45秒超时双校验；存储层用redis设置5分钟过期自动兜底；前端层通过快照+增量更新保障ui一致性。
WebSocket 在线用户状态检测要真正“实时”，关键不是堆功能，而是选对机制、控住边界、做轻决策。轮询做不到毫秒级响应，而纯靠 WebSocket 自带事件又容易误判“假在线”。实际项目里，得把连接层、状态层、存储层协同起来用。
连接层：用 onopen/onclose 做即时信号，但不单独依赖
WebSocket 的 onopen 和 onclose 是最直接的连接开关信号——用户点开页面瞬间触发 onopen，关闭标签页或网络中断时多数情况能触发 onclose。这是实时性的起点。
- 服务端收到 onopen 后立即注册用户，广播上线事件，前端同步渲染
- onclose 触发时，服务端应立刻清理内存中的连接引用，并广播下线消息
- 但要注意：移动端切后台、WiFi 切蜂窝、NAT 超时等场景下，onclose 可能延迟数秒甚至不触发，所以它只能作为“强信号”，不能作为“唯一依据”
状态层：心跳 + 最后活跃时间双校验
单靠心跳（ping/pong）会增加开销；只看最后心跳时间又可能漏判。更稳妥的做法是结合两者：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 客户端每 30 秒发一次
{"type":"ping"}，服务端响应{"type":"pong"} - 服务端为每个连接维护一个 lastActiveAt 时间戳，每次收到 ping 或业务消息就刷新
- 后台定时任务（如每 15 秒扫描）检查：若
now - lastActiveAt > 45s，则主动 close 连接并标记用户离线 - 这样既避免了高频心跳，又能控制离线判定窗口在 45 秒内，兼顾实时性与资源消耗
存储层：Redis 存状态，过期自动兜底
内存里的 Map 容易丢数据，尤其集群部署时。把在线状态落地到 Redis，既是持久化，也是兜底手段：
- 用户上线时，写入
SET user:online:123 "1" EX 300（5 分钟过期） - 每次心跳或业务消息到达，执行
EXPIRE user:online:123 300延长有效期 - 服务端 onclose 或超时清理时，显式
DEL user:online:123 - 查询某人是否在线？直接
EXISTS user:online:123—— O(1) 响应，无数据库压力
前端层：本地状态 + 服务端快照协同更新
用户看到的“在线列表”不能只等广播，否则断网重连后会空白几秒。策略是：
- 连接建立后，先请求一次
/api/online-users获取当前快照，快速填充列表 - 后续仅靠 WebSocket 消息增量更新：user-join / user-leave / status-update
- 自身状态切换（如点击“离开”）时，先改本地 UI，再发指令，避免视觉卡顿
- 断线重连成功后，自动拉取最新快照并合并差异，保证最终一致性
