如何利用 Shared Worker 实现多窗口环境下唯一的长连接维护

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