websocket无内置房间概念，需服务端用map/对象维护roomid→set映射，客户端依json协议（join/leave/message）协同管理房间状态，并处理重连一致性。
WebSocket 本身不内置“房间”概念，房间逻辑需要服务端和客户端协同实现。核心思路是：服务端维护房间与用户映射关系，客户端通过消息协议加入/离开指定房间，服务端据此转发消息或清理状态。
服务端维护房间状态（以 Node.js + ws 为例）
使用 Map 或对象管理房间，每个房间存用户连接（WebSocket 实例）集合：
- 用 roomID 作为键，值为 Set
（避免重复、方便增删） - 收到客户端“join”消息时，将当前 socket 加入对应 room 的 Set，并可广播“xxx 加入了房间”
- 收到“leave”消息或连接关闭时，从所有房间中移除该 socket；若房间为空，可选择自动销毁该 room
- 发送消息时，只遍历目标房间的 socket 集合，调用
socket.send()
定义清晰的通信协议（客户端发给服务端）
建议统一用 JSON 消息体，含 type 字段标识操作类型：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
加入房间：
{"type":"join","room":"game-123"} -
离开房间：
{"type":"leave","room":"game-123"} -
发送消息：
{"type":"message","room":"game-123","data":"hello"} - 服务端响应可返回
{"status":"ok","room":"game-123","type":"joined"}等确认信息
客户端处理房间逻辑（浏览器端）
保持一个本地变量记录当前所在房间，避免误发消息到错误房间：
- 建立连接后，先发
join消息，成功收到响应再更新currentRoom = "game-123" - 发送消息前检查
if (currentRoom)，再构造带 room 的消息体 - 页面卸载或切换房间前，主动发
leave；监听socket.onclose做兜底清理 - 可封装一个
RoomManager类，统一管理 join/leave/send/inRoom 等方法
注意断连与重连时的房间一致性
WebSocket 断开后重新连接，不会自动恢复房间状态：
- 重连成功后，客户端应重新发送
join请求（服务端需支持幂等，重复 join 同一房间不报错） - 服务端可为每个 socket 分配唯一 clientID，在重连时识别并恢复其原房间（需存储映射关系）
- 避免用户未 leave 就断开导致“幽灵用户”，可在 socket 关闭时触发延迟清理（如 5 秒后检查是否真离线）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
