WebSocket多房间隔离需服务端按房间路由广播+客户端绑定上下文：服务端用Redis管理成员并显式指定roomId推送，客户端仅处理当前房间消息，严格生命周期管理防串房。
用 WebSocket 实现多房间频道消息隔离，核心不是靠客户端“自己过滤”，而是服务端按房间做广播控制 + 客户端明确绑定上下文。关键在于消息不发错、不收错、状态不混。
服务端必须按房间做路由和广播
裸 WebSocket 本身不支持房间概念，需自行实现；推荐用 Socket.IO（封装 WebSocket 并原生支持房间）或在自研服务中用 Redis 管理房间成员。重点是：所有消息推送必须显式指定作用范围。
- 用户加入时，服务端校验 roomId 合法性（是否存在、是否满员），再调用 socket.join(roomId)
- 发消息给整个房间，用 io.to(roomId).emit('chat', msg)，而非
io.emit()（全局）或socket.emit()（仅本人） - 避免用进程内数组存房间列表（如
rooms[roomId] = [conn1, conn2]），多进程下会失效；改用 Redis 的SMEMBERS room:xxx+PUBLISH channel:xxx实现跨进程一致 - 用户断开时，在
onClose回调里主动调用socket.leave(roomId)并清理 Redis 中的成员记录，防止脏数据累积
客户端只处理当前房间的消息
前端不能依赖“收到消息后再判断 roomId 是否匹配”，而应在连接建立后，把所有业务逻辑（发送、渲染、状态更新）严格绑定到当前所处的 roomId 上。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 点击“加入房间”按钮后，向服务端 emit({ type: 'joinRoom', roomId: 'game_789', nickname: '阿哲' })
- 只在收到服务端返回的 roomJoined 事件后，才初始化游戏 UI、启动本地计时器、订阅该房间的操作事件
- 所有操作消息（如
{ type: 'move', x: 100, y: 200, roomId: 'game_789' }）都必须携带 roomId，服务端据此路由到对应房间处理 - 监听消息时，只注册 socket.on('gameUpdate', handler) 这类业务事件，不监听通用事件名（如
message），避免跨房间干扰
频道级隔离可结合 STOMP 或前缀路由
若系统需长期支持 monitor / order / stock 等不同用途的频道，建议在协议层做更严格的划分，不只是逻辑分组。
立即学习“Java免费学习笔记（深入）”；
- 使用 Spring Boot + STOMP 时，为不同频道配置独立端点（如
/ws/monitor、/ws/order），并设置不同目的地前缀（/topic/monitor、/topic/order），天然隔离 - 自研 WebSocket 服务时，可在消息体中强制要求
channel字段，并在服务端路由前校验权限与有效性，非法 channel 直接丢弃 - 大屏类应用常采用“按需订阅”模式：前端连接后先
emit('subscribe', { channel: 'stock' })，服务端才将该连接加入对应频道的广播组
别忽略连接上下文与状态清理
很多问题其实出在生命周期管理松散：连接没退出房间、状态没重置、旧连接残留监听器，都会导致消息串房或重复触发。
- 每个 WebSocket 连接应有唯一 clientID，用于跨请求识别同一用户（尤其断线重连时）
- 页面卸载或切换房间前，显式 emit('leaveRoom', { roomId: currentId })，服务端同步清理
- 前端销毁组件时，记得 socket.off('gameUpdate')，避免新房间里还响应旧房间的事件
- 服务端对长时间无心跳的连接，主动踢出并清理其所在的所有房间成员关系
