核心方案是用 localStorage 选举“主标签页”统一维护 SSE 连接，其余标签页监听 BroadcastChannel 消息实现多端共享；避免多连接触发浏览器并发限制与服务端压力。
核心思路是：用 localStorage 作为“选举协调器”，让所有同源标签页协商出一个“主标签页”来负责建立并维持 SSE 连接，其余标签页只监听 localStorage 变更或通过 BroadcastChannel 接收同步数据，避免重复连接、资源浪费和服务器压力。
为什么不能每个标签页都开 SSE？
SSE（Server-Sent Events）是单向长连接，浏览器对同一域名的并发连接数有限制（通常 6 个），且每个 SSE 连接会持续占用服务端资源。若用户打开 5 个同源标签页，每个都建 SSE，不仅浪费带宽和内存，还可能触发服务端限流或连接拒绝。真正需要的是“逻辑上一条通道，多端实时消费”。
用 localStorage 实现“主控选举”
利用 localStorage 的共享性 + storage 事件的广播特性，让所有标签页竞争成为“SSE 主控者”：
- 定义一个统一 key，例如 __sse_master_id，初始值为空或设为过期时间戳
- 每个标签页启动时检查：localStorage.getItem('__sse_master_id')
- 若为空，尝试用 localStorage.setItem('__sse_master_id', Date.now() + '_' + Math.random()) 占位；由于 localStorage 写入是原子的，**首个成功写入的标签页即当选主控**
- 若写入失败（说明已被其他页抢占），则放弃建连，转为纯监听模式
- 主控页需定期刷新 key 值（如每 30 秒重写一次时间戳），防止因页面卡死/崩溃导致“假死主控”
主控页建连 + 广播分发
主控页建立 SSE 后，不直接通知其他页 DOM，而是将消息写入 localStorage 或（更推荐）用 BroadcastChannel 分发：
立即学习“Java免费学习笔记（深入）”；
- 主控页收到 SSE 数据后，不做业务处理，先调用 bc.postMessage(data)（BroadcastChannel）广播给所有同源页
- 所有标签页（包括主控页自己）均监听 bc.onmessage，统一处理业务逻辑（如更新 UI、触发状态变更）
- 这样既规避了 storage 事件无法触发本页的限制，又避免了 JSON 序列化/反序列化的手动负担
- 若需兼容旧浏览器（如 Safari __sse_data_v123，监听 key 匹配 /^__sse_data_v\d+$/）
主控失效自动接管
主控页关闭或异常退出时，需有降级机制确保服务不中断：
- 主控页在 beforeunload / pagehide 钩子中清除 __sse_master_id
- 其他监听页发现 storage 事件中 event.key === '__sse_master_id' 且 event.newValue === null，立即触发新一轮选举
- 为防竞态，建议加 100–300ms 随机延迟再尝试抢占，减少同时写入冲突
- 也可结合 visibilitychange：当某页从 hidden 变为 visible 且未检测到有效主控，主动发起选举
这套方案不依赖后端改造，纯前端可控，已在多个中后台系统中稳定运行。关键是把“连接权”和“消费权”解耦——连接只由一人负责，消息由所有人平等接收。
