websocket需应用层实现用户活跃度管理：客户端监听交互事件并定时发ping，服务端记录最后活跃时间并定时清理超时连接，支持双向心跳、关闭码约定及角色差异化超时。
WebSocket 连接本身不内置“用户活跃度”或“超时释放”逻辑，需在应用层结合心跳机制、服务端状态跟踪与客户端行为判断来实现。核心思路是：客户端定期发送活跃信号（如心跳 ping），服务端记录每个连接的最后活跃时间，定时扫描并关闭长时间无活动的连接。
客户端：发送心跳并监听用户交互
用户活跃度不能只依赖 WebSocket 连接是否打开，而应反映真实操作（如鼠标移动、键盘输入、页面可见性变化）。客户端需：
- 监听
mousemove、keydown、scroll、visibilitychange等事件，标记“用户在线” - 使用
setInterval定期（如每 15 秒）向服务端发送{"type":"ping","ts":Date.now()}消息 - 若页面不可见（
document.hidden === true）或用户静默超 30 秒，暂停发送 ping，避免误判活跃 - 收到服务端
pong或业务响应后重置本地活跃计时器
服务端：记录活跃时间并定时清理
以 Node.js + ws 库为例，服务端需维护每个 socket 的最后活跃时间戳，并启动独立清理任务：
- 连接建立时，用
socket.lastActive = Date.now()初始化时间戳，可存入 Map 或与 socket 实例绑定 - 收到客户端 ping 或任意业务消息时，更新
socket.lastActive = Date.now() - 启动周期性检查（如每 20 秒执行一次）：
遍历所有连接，若Date.now() - socket.lastActive > 60000（即超时 60 秒），调用socket.terminate()或socket.close(4001, "inactive") - 监听
socket.on('close')和socket.on('error')，及时从活跃列表中移除该 socket
增强健壮性：双向心跳 + 关闭码约定
仅靠客户端 ping 不足以应对网络中断或客户端崩溃。建议启用 WebSocket 原生 ping/pong，并补充应用层协议：
- 服务端启用
ws.Server的pingTimeout（如 30000ms）和closeTimeout（如 5000ms），自动处理底层断连 - 客户端在
onmessage中识别{"type":"pong"}，确认服务端可达；若连续 2 次 ping 未收到 pong，主动close() - 约定关闭码：4001 表示“user inactive”，4002 表示“server timeout”，便于前端区分原因并决定是否重连
可选优化：按角色/权限设置差异化超时
并非所有用户需相同策略。例如后台管理员可设为 10 分钟超时，普通访客设为 2 分钟：
- 登录成功后，服务端在建立 socket 时附加元数据：
socket.userId = userId; socket.role = 'admin' - 清理逻辑中根据角色查表获取超时阈值：
const timeoutMs = TIMEOUT_MAP[socket.role] || 120000 - 也可结合 JWT payload 中的
exp或会话 TTL 动态计算剩余活跃窗口
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
