SharedWorker 无法直接创建 WebSocket，需主控页建连并用 BroadcastChannel 广播状态，由 SharedWorker 统一代理通信以复用 TCP 连接；需处理连接协调、精准路由、心跳保活及 Safari 兼容性降级。

SharedWorker 本身不能直接创建 WebSocket，必须靠主控页建连 + BroadcastChannel 广播状态，再由 SharedWorker 统一代理通信。这是目前唯一能真正复用单条 TCP 连接、降低服务端并发压力的方案。

主控页负责建连与状态广播

首个打开的标签页作为主控页，初始化 WebSocket，并通过 BroadcastChannel 向所有同源页面同步连接生命周期：

• 使用固定频道名，如 new BroadcastChannel('app-socket-bus')，确保所有页面和 SharedWorker 使用完全一致的字符串
• 连接成功后广播 { type: 'ws-open', id: crypto.randomUUID() }；关闭时必须广播 { type: 'ws-closed' }，否则 SharedWorker 可能继续向失效连接发消息
• 主控页需定期刷新本地状态（例如每 20 秒写入 localStorage 或再次广播），防止因页面崩溃或假死导致其他页面无法感知连接异常

SharedWorker 监听并协调页面请求

SharedWorker 不主动建连，而是等待广播就绪信号后才响应各页面的连接指令：

• 在 onconnect 回调开头就创建 BroadcastChannel 实例，保证监听时机早于任何页面通信
• 收到 'ws-open' 后，缓存连接可用状态；后续页面发来 { type: 'connect' } 请求时，不再新建连接，只登记端口与 clientId
• 页面关闭前应主动发送 { type: 'disconnect', clientId }，SharedWorker 清理映射表和订阅关系，避免内存泄漏

精准路由与连接保活

多个页面共用一条链路，但消息不能混发。SharedWorker 必须承担路由中枢职责：

• 每个页面首次通信时生成唯一 clientId（推荐 crypto.randomUUID()），注册到 SharedWorker 的映射表中
• 服务端下发消息需携带 targetClientId 或 topic 字段，Worker 解析后仅推送给匹配 port，不广播
• 心跳与重连由 SharedWorker 单点控制：用 setInterval 发送 ping，用 setTimeout + 指数退避（1s → 2s → 4s…上限 30s）处理断线重连，所有 onmessage/onerror/onclose 回调内加 trycatch

兼容性兜底不可省略

Safari 对 SharedWorker 支持较晚（iOS 16.4+/macOS 13.3+），必须设计降级路径：

• 检测 typeof SharedWorker === 'function'，不支持时 fallback 到 BroadcastChannel + 主从选举模式
• 主从选举可用 localStorage 时间戳竞拍：各页面尝试写入 ws_owner，以最新者为真主控页；失败者监听 storage 事件等待接管
• 降级后仍需保持消息路由逻辑一致——每个页面自行管理 WebSocket，但通过 BroadcastChannel 同步订阅状态与业务消息，避免重复推送