如何利用 SharedWorker 维护一个全局唯一长连接管道以降低服务器 WebSocket 负载

SharedWorker是浏览器端实现全局唯一WebSocket长连接的唯一可行方案，通过跨标签页共享线程统一管理连接、分配clientId隔离消息、内置重连心跳及状态同步，并需兼容Safari降级。

用 SharedWorker 维护全局唯一的 WebSocket 长连接，是目前浏览器端降低服务端连接数、节省客户端资源最直接有效的方式。核心在于把连接逻辑完全抽离出页面主线程，交由一个跨标签页共享的独立线程统一管理——所有窗口共用一条 TCP 连接，而非各自建连。

SharedWorker 是唯一可行的跨页面连接中枢

普通 Worker 每开一个标签页就新建一个实例；Service Worker 无法主动维持长连接，只响应事件；只有 SharedWorker 被设计为同源多上下文（tab/iframe/window）共用同一执行环境。它不依赖某个页面存活，只要还有一个同源页面打开，Worker 就持续运行，WebSocket 实例就能保持。

• 所有页面通过 同一路径 创建实例：new SharedWorker('./ws-manager.js')，路径必须完全一致（协议、域名、端口、文件名）
• Worker 内部调用 new WebSocket(url)，且仅执行一次
• 页面不能传入或共享 WebSocket 对象——它不可序列化，postMessage 会报 DataCloneError

消息路由与上下文隔离必须显式设计

单链路不等于单业务流。多个窗口共用连接后，A 窗口订阅的 topic、收到的私有消息，绝不能推送给 B 窗口。这靠的是通信协议层的标识控制，不是靠 Worker 自动分发。

• 每个页面接入时，Worker 分配唯一 clientId（如 self.crypto.randomUUID()），存入 Map<port, clientId>
• 页面发消息时必须携带 clientId，例如：{ type: "send", data: "...", clientId: "win-abc123" }
• 服务端返回的消息也应含 targetClientId 或 topic，Worker 只转发给匹配的 port，不广播
• 页面关闭前主动发 { type: "disconnect" }，Worker 清理对应 port 和订阅关系

重连、心跳与状态同步全由 Worker 承担

连接稳定性不能依赖页面逻辑。页面刷新、崩溃、切后台都会中断其 JS 执行，但 SharedWorker 仍可运行并维持连接。所有保活动作必须下沉到 Worker 内：

• 使用 setInterval 发送 "ping"，服务端需响应 "pong"；连续两次无响应即触发断连重试
• 断连后执行指数退避重连（1s → 2s → 4s → … 最大 30s），避免雪崩请求
• 重连成功后，自动重发各窗口缓存的 subscribe 请求（需在 Worker 内维护订阅快照）
• 通过 port.postMessage({ type: "status", state: "connecting" }) 向所有页面同步连接状态，UI 可据此更新指示器

兼容性与降级策略要提前兜底

Safari 对 SharedWorker 的支持较晚（iOS 16.4+ / macOS 13.3+），且部分旧版本存在端口泄漏问题。生产环境必须准备 fallback：

• 检测 typeof SharedWorker !== 'undefined'，不支持时退回到页面各自建连 + BroadcastChannel 同步关键状态（如登录态、连接意图）
• Worker 内避免使用 localStorage（不可用），但可安全调用 fetch、IndexedDB 做本地缓存
• MQTT 场景需用浏览器版 mqtt.min.js，通过 importScripts() 加载，并确保 client.connected === true 后再订阅