WebSocket 协议本身不支持原生多路复用，但可通过应用层设计在单个连接上模拟多个逻辑通道：消息携带路由标识（如roomID）、用Map管理通道专属监听器、协商子协议与压缩扩展、联动心跳管理通道生命周期，实现高效隔离的消息分发。
WebSocket 协议本身不支持原生多路复用，但前端可以通过应用层设计，在**单个连接上模拟多个逻辑通道**，实现高效、隔离的消息分发。关键不是“复用连接”这个动作本身，而是如何让不同业务模块共用一个 socket，又互不干扰。
消息带路由标识，统一连接收发
所有消息都走同一个 WebSocket 实例，但每条消息必须携带明确的上下文字段，比如 roomID、channel 或 type：
- 发送时自动注入当前场景标识：{"type":"chat","roomID":"team-101","content":"收到"}
- 服务端按该字段做精准广播或单播，不泛洪
- 客户端收到后，不再全局处理，而是提取 roomID 去匹配对应模块逻辑
- 切换聊天室、通知频道等场景时，只更新本地标识变量，不重连、不新建 socket
用 Map 管理通道专属监听器
避免在 socket.onmessage 里堆 if-else 判断类型，改用 Map 存储各通道的回调函数：
- 进入房间 A 时：
listeners.set("team-101", (data) => renderChat(data)) - 离开时及时
delete listeners.get("team-101")，防止内存泄漏 - 收到消息后：
const handler = listeners.get(data.roomID); handler?.(data) - 每个通道的 UI 更新、状态管理完全独立，天然解耦
配合子协议与压缩扩展提升能力
握手阶段可协商额外能力，为多通道场景提供支撑：
- 指定子协议如
["chat-v2", "notify-v1"]，帮助服务端识别语义层级，辅助路由决策 - 启用
permessage-deflate压缩扩展，对高频小消息（如心跳、光标同步）自动压缩，降低带宽压力 - 子协议需前后端一致约定；压缩由浏览器和服务器自动完成，前端无需手动编解码
心跳联动通道生命周期
单连接承载多通道时，需主动管理通道活跃状态：
- 为每个逻辑通道设置独立的心跳超时计时器
- 某通道长时间无消息，可自动触发清理：移除监听器、释放 UI 组件、通知服务端退订
- 心跳响应也应携带 roomID，确保服务端能精准续期对应通道会话
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
