websocket 多房间通过单连接+roomid字段实现复用与隔离：前端复用一个实例并维护currentroom，收发消息均携带roomid；服务端按roomid路由，客户端用map管理各房间监听器，配合发送校验与接收过滤双重保障，并需清理无效监听器防泄漏。
WebSocket 本身是单连接、全双工的通信通道，不原生支持“多房间”概念；所谓多聊天房间切换时的通道复用与消息隔离，本质是在**同一个 WebSocket 连接上，通过应用层协议设计实现逻辑上的房间划分与消息路由**。关键不在“创建多个 socket”，而在于“如何发、如何收、如何区分”。
用统一连接 + 房间标识字段实现复用
前端只维护一个 WebSocket 实例（避免频繁重连、资源浪费），所有房间消息都走这条连接。服务端和客户端约定：每条消息必须携带 roomID 字段（如 {"type":"message","roomID":"room-123","content":"hi"}）。前端发送时主动附带当前房间 ID；接收时根据 roomID 决定把消息分发给哪个房间的 UI 组件或状态管理模块。
- 切换房间时，不关闭 socket，只更新本地“当前活跃房间”变量（如
currentRoom = 'room-456'） - 发消息前，自动注入当前
roomID，无需为每个房间新建连接 - 服务端按
roomID转发消息，不广播给所有客户端，保证跨房间消息隔离
用 Map 管理房间级消息监听器
避免全局 onmessage 中写一堆 if-else 判断房间，推荐用 Map 存储每个房间的独立回调函数：
- 进入房间 A 时：
roomListeners.set('room-A', (msg) => updateChatUI(msg)) - 离开房间 A 时：
roomListeners.delete('room-A') - 收到消息后：
const listener = roomListeners.get(data.roomID); if (listener) listener(data)
这样既解耦了各房间逻辑，又确保只有目标房间的监听器响应消息，天然实现消息隔离。
发送前校验 + 接收后过滤，双重保障隔离
仅靠服务端转发还不够稳健。前端应主动做两层防护：
-
发送侧：切换房间后，新发的消息若仍含旧房间 ID，服务端应拒绝或修正 —— 前端可在 send 前加一层封装，强制使用
currentRoom -
接收侧：即使服务端误发，前端也需检查
data.roomID === currentRoom，非当前房间的消息直接丢弃或暂存（如用于未读数统计）
例如用户在房间 B，却收到房间 A 的消息，UI 不渲染，但可触发 badge 提示“你在房间 A 有新消息”。
清理机制防内存泄漏
频繁进出房间容易积累无效监听器或未清除的定时任务（如心跳、重连）。建议：
- 每个房间实例绑定唯一 key（如
roomId + userId），退出时彻底清除对应监听器、定时器、DOM 事件 - 利用 AbortController 或自定义 destroy 方法，在组件卸载/路由离开时触发清理
- 对长期空闲的房间连接（如 30 分钟无操作），可主动发 leave 指令通知服务端释放资源
不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
