SharedWorker 是浏览器端唯一支持跨标签页复用 WebSocket 以降低服务端并发连接数的机制，需同源 HTTPS/localhost 运行，连接逻辑、重连、心跳、消息路由（含 clientId 隔离）及状态同步均须在 Worker 内实现。
SharedWorker 是目前浏览器端唯一能真正复用 WebSocket 实例、从而降低服务端并发连接数的机制。它不是“理论上可行”，而是唯一被浏览器内核支持的跨标签页共享连接方案——其他方式（BroadcastChannel + 主页面代理、localStorage 轮询、Service Worker 中转）都绕不开多连接或状态错乱问题。
SharedWorker 必须在同源 HTTPS 或 localhost 下运行
浏览器会静默拒绝非安全上下文中的 new SharedWorker() 调用，连 onerror 都不会触发。开发阶段必须确认：
- 本地调试用
http://localhost:port，不能用file://协议 - 上线后必须是
https://，HTTP 域名即使同源也会直接失败 - Safari 仅支持 macOS 13.3+ / iOS 16.4+，旧版本需 fallback 到单页独连
WebSocket 实例必须且只能在 SharedWorker 内创建
常见错误是试图在页面中 new WebSocket() 后通过 postMessage 传给 Worker——这会抛出 DOMException: Failed to execute 'postMessage' on 'MessagePort'，因为 WebSocket 对象不可序列化。
- 所有连接逻辑（
new WebSocket(url)、onopen、onmessage、onclose）必须写在shared-worker.js中 - Worker 收到页面发来的
{ type: "connect", url: "wss://..." }后，需先检查ws?.readyState === WebSocket.CLOSED才新建实例，避免重复new - 页面不能持有或操作
WebSocket实例，只负责发送指令和接收转发消息
消息路由必须显式携带 clientId 并隔离分发
单链路不等于单业务流。多个窗口共用一条连接后，A 窗口订阅的 topic、收到的私有消息，绝不能推送给 B 窗口——这不是 Worker 自动做的，而是靠协议层标识控制。
- 页面首次接入时发
{ type: "init", clientId: self.crypto.randomUUID() } - Worker 用
Map<port clientid></port>存储映射关系，并在校验port.onmessage时强制要求字段存在 - 服务端返回的消息必须含
targetClientId或topic，Worker 查表后只调用对应port.postMessage() - 页面关闭前主动发
{ type: "disconnect", clientId: "..." }，Worker 清理映射与缓存的订阅快照
重连、心跳、状态同步必须全部下沉到 SharedWorker 内部
如果把重连逻辑放在页面里，多个标签页会同时触发重连请求，造成服务端雪崩；如果依赖主线程定时器，页面切后台后心跳会失效。
- 使用
setInterval发送"ping"，服务端需响应"pong"；连续两次无响应即ws.close()并触发重连 - 断连后执行指数退避：1s → 2s → 4s → … 最大 30s，避免连接风暴
- 重连成功后，自动重发各窗口缓存的
subscribe请求（需在 Worker 内维护订阅快照） - 通过
port.postMessage({ type: "status", state: "connecting" })向所有页面同步状态，UI 可据此更新指示器
最易被忽略的一点：SharedWorker 的端口数有硬性限制（Chrome 约 100–200 个），超过后新标签页调用 new SharedWorker() 会静默失败。千级标签页场景下，必须降级为 BroadcastChannel 分片 + localStorage 同步，而非强行堆叠 SharedWorker 实例。
