WebSocket配合Socket.IO的房间机制可实现实时多人互动游戏，服务端用roomId管理分组与状态同步，客户端按房间隔离消息与UI，支持动态创建销毁、状态快照与断线重连。
WebSocket 是实现实时多人互动游戏的核心技术，配合房间（Room）机制，可以精准控制用户分组、消息广播范围和状态同步。关键在于服务端维护房间状态，客户端按房间 ID 加入/离开，并只接收本房间消息。
服务端：用 Node.js + Socket.IO 管理房间
Socket.IO 封装了 WebSocket 并兼容降级，同时原生支持房间（join/leave）和房间内广播（to(roomId).emit()），比裸 WebSocket 更适合开发。
- 每个房间用唯一字符串标识，如
"room_abc123"或由服务端生成的 UUID - 用户连接后不自动加入任何房间；需显式发送
joinRoom事件并携带 roomId 和可选昵称 - 服务端验证 roomId 合法性（如是否已存在、是否满员），再调用
socket.join(roomId) - 向房间内其他成员广播“新玩家加入”，但不发给本人（用
socket.to(roomId).emit()） - 断开连接时自动从所有房间退出，也可监听
disconnect手动清理（如保存房间快照）
客户端：按房间隔离消息与 UI
前端需明确区分“全局连接”和“房间上下文”。WebSocket 连接是全局的，但所有游戏逻辑（移动、出牌、计分）都应绑定到当前所处的 roomId。
- 页面加载后建立 socket 连接，但不立即加入房间；先展示房间列表或创建表单
- 点击“加入房间”时，向服务端 emit
{ type: 'joinRoom', roomId: 'xxx', nickname: '小明' } - 监听服务端返回的
roomJoined事件，成功后才渲染游戏区域、初始化本地状态 - 所有游戏操作（如
moveLeft、shoot）都带上当前 roomId，服务端据此路由到对应房间处理 - 监听
inRoom类型事件（如playerMoved、gameStarted），且仅在处于对应 roomId 时更新 UI
房间生命周期与状态同步要点
房间不是静态容器，需支持动态创建、销毁、状态快照与重连恢复。
立即学习“前端免费学习笔记（深入）”；
- 房间可设最大人数（如 4 人），满员后拒绝新加入请求，或转为观战模式
- 首个玩家创建房间时，服务端生成 roomId 并存入内存 Map 或 Redis（需分布式时）；空闲超时（如 5 分钟无用户）自动销毁
- 关键状态（如棋盘格子、玩家血量、倒计时）建议由服务端统一维护，客户端只发操作指令，避免作弊和不一致
- 用户意外断线后，可在一定时间内（如 30 秒）尝试重连并恢复房间状态，服务端保留其临时 seat 位
- 使用
socket.rooms可查当前 socket 所在的所有房间，用于权限校验或跨房间通信（如管理员广播）
一个最小可行示例：房间内实时画板
两人以上进入同一 roomId 后，一人画线，其余人实时看到——这是验证房间机制是否生效的最快方式。
- 服务端：监听
drawLine事件，校验 roomId 存在且用户已加入，再io.to(roomId).emit('lineDrawn', data) - 客户端：canvas 绑定鼠标事件，绘制时 emit
{ type: 'drawLine', roomId, points: [...] }；收到lineDrawn即在 canvas 上重绘 - UI 层显示当前房间号、在线人数、离开按钮（触发
leaveRoom事件） - 网络异常时显示 “正在重连…” 并暂停发送，恢复后补发未确认的操作（可选）
