Shared Worker 是唯一能实现多窗口共用单条 WebSocket 长连接的方案，因其可跨同源页面共享执行环境、支持单例 WebSocket 实例创建与统一管理，而 BroadcastChannel 等仅能通信无法复用连接；WebSocket 必须在 Worker 内创建，不可序列化传输；需为每页分配唯一 clientId 实现精准消息路由，并由 Worker 全权负责重连、心跳、状态同步与端口生命周期清理。
SharedWorker 必须在 worker 内创建并维持 WebSocket 实例
页面无法把 WebSocket 对象传给 SharedWorker —— 它不可序列化，postMessage 会直接抛 DataCloneError。所有连接逻辑必须下沉到 worker 脚本里：new WebSocket()、onopen、onmessage、onerror 全部在 shared-worker.js 中完成。
常见错误是页面先连上再把 socket 引用发过去，结果卡在第一步就失败。正确做法是页面只发指令，比如：
{ type: "connect", url: "wss://api.example.com/ws" }{ type: "send", data: { action: "subscribe", topic: "user/123" } }
SharedWorker 收到后才执行实际连接，并缓存 ws 实例供后续复用。
每个窗口需带唯一 clientId 才能精准路由消息
多个页面共用一条链路，但服务端下发的消息不能混发。SharedWorker 必须为每个接入窗口分配唯一标识，否则 A 窗口可能收到 B 的私有通知。
推荐用 self.crypto.randomUUID() 生成 clientId（现代浏览器支持），旧环境可用 Date.now() + Math.random().toString(36).substr(2, 9) 组合。窗口初始化时发送：
{ type: "init", clientId: "win-8f3a1e7b" }
后续所有业务消息都携带该字段，SharedWorker 转发时只推给匹配 port，不广播。服务端下发消息也应含 targetClientId 或 topic，worker 做白名单比对，而非无脑 ports.forEach(port => port.postMessage(...))。
重连、心跳、状态同步必须由 SharedWorker 单点控制
页面失焦、崩溃、刷新都不该导致连接中断。SharedWorker 的生命周期独立于单个页面：只要还有一个同源页面存活，worker 就继续运行，WebSocket 也能保持。
但 worker 自身不自动重连，必须手动实现健壮逻辑：
- 用
setTimeout实现指数退避（1s → 2s → 4s → 最大 30s），避免雪崩 - 心跳用
setInterval发送"ping"，连续 2 次未收到"pong"就主动ws.close() -
ws.onopen和ws.onmessage回调内必须包try...catch，否则未捕获异常会让整个 SharedWorker 退出 - 连接恢复后，要重发各窗口缓存的
subscribe请求，否则订阅关系丢失
页面侧只需监听 status 类型消息（如 { type: "status", state: "connected" }），更新 UI 指示器即可，无需参与重连决策。
页面关闭或崩溃时，SharedWorker 如何清理资源
SharedWorker 不会因某个页面崩溃而终止，但它需要知道哪些 port 已失效，否则内存泄漏、消息错发、重连失败都会发生。
关键动作是：页面在 beforeunload 或 visibilitychange 为 hidden 时，主动发 { type: "disconnect", clientId: "win-8f3a1e7b" }；SharedWorker 收到后从 Map 或 Array 中移除对应 port 和订阅关系。
若页面崩溃没来得及发断开消息，SharedWorker 可监听 port.onclose（部分浏览器支持）或依赖浏览器行为：当页面进程终止，其持有的 port 会自动关闭，onmessage 不再触发。但不要依赖这个——务必让页面主动通知，这是最可控的方式。
最后一点容易被忽略：SharedWorker 在最后一个 port 关闭后约 10–30 秒才会被浏览器回收，这段时间内它仍可能尝试重连。所以 ws.close() 后应清空定时器、取消所有 setTimeout/setInterval，防止残留任务报错。
