多房间本质是显式维护“用户-房间”订阅关系，而非依赖路径；需用concurrenthashmap或redis存储映射，严格在连接/断连时增删，并按消息内roomid精准广播。
直接用 @ServerEndpoint 做多房间，不加中间状态管理，消息必然串房、漏发、无法退订——这不是 WebSocket 的能力问题，是设计没对齐 Pub/Sub 语义。
WebSocket 多房间必须自己维护订阅关系表
Java 原生 javax.websocket 没有内置“频道”概念，@ServerEndpoint("/ws/{roomId}") 只是路径参数，不能自动隔离会话。一旦多个用户连到同一个 /ws/room1，你得靠自己代码把他们归到一个逻辑房间里，并支持动态加入/退出。
- 用
ConcurrentHashMap<string copyonwritearrayset>></string>存房间 ID 到 Session 集合的映射，别用普通HashMap+synchronized，高并发下容易锁死 - 每次
@OnMessage收到消息时，先解析 JSON 中的"roomId"字段，再查对应集合广播，不能只依赖 URL 路径——URL 是连接入口，不是运行时路由依据 - 客户端断开时，
@OnClose必须从所有它订阅过的房间集合中移除该Session，否则内存泄漏 + 消息误推
Spring Boot + STOMP 模式下如何正确声明多主题（topic）
用 spring-boot-starter-websocket + STOMP 时，/topic/room.{id} 这类路径不是“自动创建房间”，而是 Spring 的 SimpleBroker 或 StompBrokerRelay 对订阅路径的匹配规则。真正起作用的是客户端发送的 SUBSCRIBE 帧里的 destination。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 服务端配置里
registry.enableSimpleBroker("/topic", "/queue")后，所有以/topic/开头的 destination 才会被代理识别为广播主题 - 前端 JS 订阅必须写成
stompClient.subscribe('/topic/room.101', callback)，不是/ws/topic/room.101—— 多余路径前缀会导致 404 或静默失败 - 后端用
simpMessagingTemplate.convertAndSend("/topic/room.101", msg)推送，注意 destination 必须和订阅路径完全一致，大小写、点号、斜杠都不能错
PHP 实现 WebSocket 多房间时最常踩的坑
PHP 没有 JVM 级别的 Session 生命周期管理，reactphp/websocket 或 workerman 启动的服务器进程里，每个连接都是独立的 Connection 对象。所谓“房间”，全靠你自己在内存或 Redis 里存映射关系。
- 别在
onMessage里直接foreach($connections as $conn) $conn->send(...)—— 这会把消息发给所有连接，不管它在不在这个房间 - 用 Redis 的
SET结构存room:101 → [conn_id_1, conn_id_2]，每次推送前SMEMBERS room:101拿连接列表，再挨个send() - 客户端断开时，
onClose回调里必须主动执行Redis::sRem("room:101", $conn_id)，否则下次有人发消息，僵尸连接还会被遍历到，导致Connection reset错误日志刷屏
前端订阅多个房间时如何避免消息混淆
一个用户可能同时在“技术讨论”和“水群”两个房间，前端 Stomp 客户端返回的 subscription 对象必须保留引用，否则 unsubscribe() 会失效，或者不同房间的消息回调混在一起处理。
- 不要写
stompClient.subscribe('/topic/room.101', handler)然后丢掉返回值；应存为this.techSub = stompClient.subscribe(...) - 切换房间时，先
this.techSub.unsubscribe()，再this.waterSub = stompClient.subscribe('/topic/room.102', ...) - handler 函数里别直接操作全局 DOM 元素，先判断当前激活的 roomId 是否匹配消息里的
roomId字段，防止 A 房间消息渲染到 B 房间 UI 上
多房间的本质不是“分路径”，而是“分状态”。无论用哪种语言，只要没把“谁在哪个房间”这个映射关系显式建模并严格维护，就一定会在高并发或异常断连场景下出错——这个逻辑层，没人能替你写。
