核心是将 WebSocket 连接作为有状态、可追踪、可复用的资源统一管理，需通过业务标识绑定会话、集中托管生命周期、信封式消息路由、资源隔离与熔断机制来保障稳定性。
在复杂应用中管理多路 WebSocket 连接，核心不是“同时开多个 new WebSocket()”，而是把连接当成有状态、可追踪、可复用的资源来组织。实际项目里，一个用户可能同时打开多个标签页、多个功能模块（如聊天窗口、实时看板、协作白板），甚至跨设备登录——这些都会触发多路连接，若不做统一管控，极易出现消息错发、内存泄漏、心跳冲突、重复鉴权等问题。
连接标识与会话绑定
每个 WebSocket 实例必须关联唯一业务上下文，不能只靠 ws.url 或随机 ID 区分。推荐做法是：在握手阶段通过 URL 参数或子协议（protocols）携带业务标识，例如：
ws://api.example.com/ws?module=chat&roomId=1001&userId=U789- 或使用子协议：
new WebSocket(url, ['chat-v2', 'user-U789'])
服务端据此生成带业务维度的会话 ID（如 chat:U789:1001），前端也用同样规则构建本地连接 Map，比如：connections.set('chat-1001', ws)，便于按模块精准操作。
连接生命周期集中托管
避免在各业务组件里零散创建/关闭连接。应封装一个连接管理中心类，统一处理：
立即学习“Java免费学习笔记（深入）”；
- 连接复用：相同 module + roomId 的请求，优先返回已存在的 OPEN 状态连接
- 自动重连：内置退避策略（如指数增长延迟），并限制最大重试次数
- 优雅关闭：调用
ws.close(1000, 'page-unload')，并在onclose中清理对应 entry - 标签页可见性联动：监听
document.visibilityState，隐藏时暂停心跳、降级为低频保活
消息路由与类型分发
多路连接共存时，收到的消息必须能准确投递给对应模块。不建议让每个连接独自解析全部消息。推荐采用「信封+分发器」模式：
- 所有消息统一包装成标准信封：
{ type: 'chat.message', data: {...}, target: 'chat-1001' } - 客户端全局监听
onmessage，由中心分发器根据target或type转发给注册了该事件的模块 - 模块通过
connection.on('chat.message', handler)订阅，解耦连接实例与业务逻辑
资源隔离与异常熔断
防止某一路连接异常（如频繁断连、大量错误帧）拖垮整个通信层：
- 为每类连接设置独立心跳周期和超时阈值（如 chat 连接 30s 心跳，监控看板 60s）
- 记录单连接错误率，连续 3 次
onerror后暂停该连接的自动重连，转为人工触发恢复 - 内存中限制总连接数（如最多 8 路活跃连接），超出时按 LRU 清理最久未通信的非关键连接
