多标签页 websocket 同步的核心是共用同一条 tcp 连接，sharedworker 是唯一原生复用方案；broadcastchannel 仅协调生命周期；每页需唯一 clientid 实现精准消息路由；safari 降级为 broadcastchannel + localstorage 竞拍。
多标签页中同步 WebSocket 状态，核心不是“共享一个 WebSocket 实例”，而是让所有标签页共用**同一条 TCP 连接**，并通过协调机制确保状态一致、消息不乱、关闭可感知。直接在每个页面 new WebSocket() 会造成连接爆炸、资源浪费、状态割裂——这不是同步，是并发污染。
SharedWorker 托管连接，唯一真复用方案
SharedWorker 是目前唯一能真正复用单条 WebSocket 连接的浏览器原生机制：
- 它运行在独立上下文，所有同源标签页共享同一个 Worker 实例
- Worker 内部可直接调用 new WebSocket()，并完整管理 onopen/onmessage/onclose/重连/心跳
- 页面只通过 port.postMessage() 发送指令（如 {type: "send", data: ...}）或注册 clientId，不碰连接本身
- 服务端返回消息时，Worker 按 clientId 路由到对应页面，避免跨页渲染错乱
- Safari 16.4+ / macOS 13.3+ 支持；旧版需降级兜底（见下文）
BroadcastChannel 同步生命周期事件
BroadcastChannel 不负责通信，只做轻量广播，解决“谁主控”“是否在线”这类协调问题：
- 固定频道名（如 "ws-bus"），所有页面和 SharedWorker 都监听同一频道
- SharedWorker 连接成功后发 {type: "connected", timestamp: Date.now()}，其他页面收到即停止建连尝试
- SharedWorker 断连时发 {type: "ws-closed"}，各页面可触发 UI 提示或启动重试逻辑
- 主控页关闭前主动广播 {type: "disconnect"}，剩余页面基于 localStorage 时间戳竞选出新主控
每个页面必须绑定唯一 clientId
即使连接复用，数据仍需精准投递，否则 A 标签页的操作会错误更新 B 标签页的 DOM：
- 页面初始化时生成唯一标识：const clientId = crypto.randomUUID() || Date.now().toString(36)
- 首次向 SharedWorker 发送注册消息，Worker 记录 clientId → port 映射关系
- 服务端下发消息时，必须携带 targetClientId 或 clientId 列表，不能盲目广播
- 前端收到消息后，先校验 payload.clientId === 当前页面 clientId，再执行 setState 或 DOM 更新
- 对状态类消息（如编辑内容、拖拽位置），建议附加 version 或 timestamp，防止旧状态覆盖新状态
Safari 兼容性兜底策略
SharedWorker 在 Safari 中支持较晚且存在稳定性问题，需降级为 BroadcastChannel + localStorage 竞拍模式：
- 所有页面监听同一 BroadcastChannel，并读写 localStorage 中的 owner 字段
- 页面打开时检查 localStorage.owner 是否为空或已过期（加时间戳判断），为空则尝试写入自己 clientId 并建立 WebSocket
- 监听 storage 事件：当 owner 变更，非主控页清除自身 WebSocket 并切换为监听模式
- 主控页定期刷新 localStorage.owner 时间戳，超时未刷新则自动释放权限
- 该方案无法复用 TCP 连接，但能保证逻辑上“只有一个活跃连接”，比全量并发好得多
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
