SharedWorker 是浏览器端唯一能复用 WebSocket 降低服务端并发连接的机制，但需满足同源 HTTPS/localhost 环境、Safari 版本兼容、连接逻辑全下沉至 Worker、显式 clientId 路由、单点重连与心跳、端口数限制规避等严苛条件。
SharedWorker 是目前浏览器端唯一能真正复用 WebSocket 实例、降低服务端并发连接数的机制，但它的可用性高度依赖环境合规性与逻辑下沉程度——不是“用了就能降压”，而是“写对了才有效”。
SharedWorker 必须在同源 HTTPS 或 localhost 下运行
浏览器会静默拒绝非安全上下文中的 new SharedWorker() 调用，连 onerror 都不会触发。开发阶段必须确认：
- 本地调试用
http://localhost:port，不能用file://协议 - 上线后必须是
https://，HTTP 域名即使同源也会直接失败 - Safari 仅支持 macOS 13.3+ / iOS 16.4+，旧版本需 fallback 到单页独连（如用
localStorage+storage事件同步状态）
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.OPEN，未连接才新建，避免重复new - 页面只发指令，不碰连接；Worker 才是连接的唯一持有者和生命周期管理者
消息路由必须显式携带 clientId 并做端口隔离
单条 WebSocket 不等于单业务流。A 页面订阅 order/123，B 页面订阅 chat/456，它们的数据绝不能混发——Worker 不自动分发，全靠协议层标识控制。
- 页面首次通信时生成唯一
clientId（推荐self.crypto.randomUUID()），随{ type: "init", clientId: "tab-abc123" }发送 - Worker 用
Map<port clientid></port>维护映射，并在校验通过后才接受该 port 的后续消息 - 服务端返回的消息必须含
targetClientId或topic，Worker 查表后只调用对应port.postMessage()，不广播 - 页面关闭前主动发
{ type: "disconnect", clientId: "tab-abc123" }，Worker 清理映射与缓存的订阅关系
重连、心跳、状态同步必须全部下沉到 SharedWorker 内部
把重连逻辑放在页面里，多个标签页会同时触发重连请求，造成服务端雪崩；依赖主线程定时器，页面切后台后心跳就失效。这些都必须由 Worker 单点控制：
- 用
setInterval发送"ping"，服务端需响应"pong"；连续两次无响应即ws.close()并触发重连 - 断连后执行指数退避：1s → 2s → 4s → … 最大 30s，避免重试风暴
- 重连成功后，自动重发各窗口缓存的
subscribe请求（需在 Worker 内维护订阅快照） - 通过
port.postMessage({ type: "status", state: "connecting" })向所有页面同步状态，UI 可据此更新指示器
最容易被忽略的是端口数硬限制：Chrome 当前对单个 SharedWorker 实例的并发 MessagePort 数设限约 100–200 个，超过后新标签页调用 new SharedWorker() 会静默失败。千级标签页场景下，必须改用 BroadcastChannel 分片或 localStorage + storage 事件降级，而非强行堆叠 SharedWorker。
