SharedWorker不可用时优先fallback到BroadcastChannel，需检测其可用性、统一频道名并配合localStorage+storage事件实现主控选举与心跳保活，页面刷新后须重建clientId等上下文以保障消息路由正确。
SharedWorker不可用时BroadcastChannel怎么 fallback
当 SharedWorker 不可用（比如 iOS Safari 16.3 或更早、部分安卓 WebView），BroadcastChannel 是最轻量且兼容性最好的第一级降级方案。但它在隐私模式下可能被禁用，需配合检测逻辑。
- 先检查
typeof BroadcastChannel !== 'undefined'，再创建频道，避免报错 - 频道名必须严格一致（如
'ws-control'），否则跨页通信失败 - 主控页通过
bc.postMessage({ type: 'connected', wsId: 'xxx' })广播连接就绪；从属页只监听，不建连 - 主控页关闭时会触发
beforeunload发送{ type: 'disconnect' }，但不可靠——需额外加心跳检测
localStorage + storage事件如何模拟分布式锁
BroadcastChannel 失效时（如无痕模式），用 localStorage 写时间戳实现简易主控选举，本质是“谁先写成功谁当主控”，但必须处理竞态和假死。
- 每个页面启动时读
localStorage.getItem('ws_owner')，若为空或超时（如 >35 秒），尝试localStorage.setItem('ws_owner', Date.now().toString()) - 写入成功即成为主控页，立即启动
WebSocket；失败则进入从属状态，监听storage事件 - 主控页每 20 秒刷新一次
ws_owner值，从属页用setInterval检测是否超时，超时即重新竞拍 - 注意：
storage事件在当前页无法触发自身写入，只通知其他页 —— 这是设计使然，不是 bug
页面刷新后如何重建连接上下文
无论用哪种降级方案，页面刷新都会丢失内存状态（如 clientId、订阅列表、未响应请求队列），必须主动重建，否则消息路由失效或重复发送。
- 每个页面首次加载生成唯一
clientId（推荐crypto.randomUUID()），并存入sessionStorage，刷新后复用 - 主控页重启后，需重发
{ type: 'reconnect', clientId }给所有从属页，触发它们同步本地状态 - 从属页收到新连接广播后，应清空旧的待处理消息缓存，避免把上一次会话的响应误推给当前 UI
- 服务端需支持按
clientId重放未确认消息（可选），前端至少保证“不丢不重”基础语义
为什么不能只靠轮询兜底
纯 setInterval 轮询（如每 3 秒查一次 localStorage）看似简单，但实际会掩盖真实问题，且引入不可控延迟和资源浪费。
立即学习“前端免费学习笔记（深入）”；
- 轮询间隔太短（
- 轮询无法感知连接建立瞬间，必然比
BroadcastChannel或storage事件慢 1～2 个周期 - 多个页面同时轮询，容易触发服务端限流或数据库压力，尤其在高并发登录态同步场景
- 真正该轮询的只有“主控页是否还活着”这一件事，其他都该走事件驱动 —— 把轮询当作保底，而非主力
clientId 生命周期和消息投递规则，否则 A 页刷新后收不到自己发的请求响应，这种错乱很难排查。 
