关键在于连接管理、状态同步与断线重连：用map存储连接并配心跳检测，redis管理房间状态实现解耦，采用差分同步与客户端预测+服务端矫正，依赖心跳而非onclose判断连接活性，重连时需服务端校验并重置本地输入。
WebSocket 实现多人游戏，关键不在“能不能连上”，而在于“连上之后怎么管人、怎么同步、怎么不死”。用错架构，50 个玩家就卡顿；选对路子，单机扛住 5000+ 并发也常见。
WebSocket 连接管理：别让 wss.on('connection') 成为性能瓶颈
很多人一上来就写 wss.on('connection', (ws) => { ... })，然后在回调里直接存 ws 到全局数组——这在开发阶段没问题，上线后会出事。
- 每个
ws实例自带缓冲区和事件队列，不加节制地保存引用，内存泄漏风险高 - 没有心跳检测时，断网客户端的连接不会自动关闭，
ws.readyState可能长期卡在1（OPEN），但实际已收不到数据 - Node.js 的
EventEmitter默认最大监听器数是 10，大量玩家加入后容易触发MaxListenersExceededWarning
实操建议：
- 用 Map 替代数组存储连接：
const clients = new Map<string websocket>()</string>，用sessionId或随机 ID 做 key，避免遍历查找 - 连接建立后立刻发送心跳包，并启动定时器检查
ws.isAlive（需配合ws.ping()和ws.on('pong', ...)） - 收到消息前先校验
ws.readyState === WebSocket.OPEN，否则直接丢弃，不进业务逻辑
房间（Room）系统：用 Hash 而不是数组管理玩家
房间不是“一群人在同一个 URL 上连着”，而是服务端显式维护的状态容器。用数组 push/pop 玩家，会导致广播时反复 filter、find，O(n) 操作在千人房间里就是延迟来源。
- Redis 的
HSET room:123 player:abc '{"x":100,"y":200}'是推荐做法，不是可选优化——它把房间成员关系和状态解耦，支持多进程扩缩容 - 服务端 Room 类里不要存
WebSocket实例，只存playerId和必要元数据（如角色类型、输入延迟补偿值） - 玩家离开房间时，必须原子性地：从 Redis 删除记录 + 向剩余成员广播
{type: 'playerLeave', playerId}+ 清理本地缓存
常见错误：前端发 {type: 'leaveRoom'}，服务端只删了本地数组，没碰 Redis —— 下次服务器重启，这个玩家还在“房间里”。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
状态同步策略：权威服务器 ≠ 每帧全量广播
权威（server-authoritative）不是指“所有计算都在服务端做”，而是指“唯一可信状态源在服务端”。盲目每 16ms（60fps）广播整个世界状态，带宽和 CPU 都扛不住。
- 用差分同步（delta sync）：只推送变化字段，比如
{id: 'p42', x: 105.2, y: 201.7}，而不是整个玩家对象 - 设置合理
patchRate：Colyseus 默认 50ms（20fps），五子棋类回合制可降到 500ms；FPS 类建议 33ms（30fps），再快客户端插值也跟不上 - 客户端预测 + 服务端矫正：移动指令发到服务端后，前端立即执行本地预测；收到服务端确认帧时，用插值或回滚修正位置
注意：serializePayload() 在 Lance.js 里默认走二进制序列化，但如果你用 JSON，务必禁用 JSON.stringify 对 undefined / function / NaN 的处理——它们会变成 null，导致客户端状态错乱。
断线与重连：别信 onclose 能捕获所有异常
ws.on('close') 只能捕获正常关闭或协议级断开，网络抖动、NAT 超时、代理中断等场景下，ws 实例可能静默失联，readyState 还是 OPEN。
- 必须依赖心跳机制：服务端每 10s 发
ping，客户端收到后立即回pong；超时 3 次未响应，强制ws.terminate() - 重连时不要重建 WebSocket 实例后直接 joinRoom，要先请求
/reconnect?roomId=123&playerId=abc接口，服务端校验该玩家是否仍在房间、状态是否有效 - Redis 中房间状态要带 TTL，比如
EXPIRE room:123 300（5 分钟），防止断线玩家永久占坑
最容易被忽略的一点：重连成功后，客户端必须丢弃所有未确认的本地输入，以服务端最新帧为基准重新开始预测——否则会出现“自己穿墙”或“技能放空”的诡异现象。
