shared worker 本身不是单点故障源，而是唯一能避免单点故障的设计载体；需通过错误监听、双通道降级、service worker 协同及 broadcastchannel 状态同步实现高可用。
shared worker 本身不是单点故障源，而是唯一能避免单点故障的设计载体——它天然跨标签页共享、独立于页面生命周期运行。所谓“全站瘫痪”，实际是误将 shared worker 当作可选组件，或未按其运行机制做容错设计所致。真正要防的，不是 worker 崩溃，而是页面与 worker 协同失当引发的级联失效。
Worker 崩溃不可怕，可怕的是没监听 onerror 和 onclose
Shared Worker 运行在独立线程，但并非永不崩溃。JS 异常、内存溢出、未捕获的 promise rejection 都可能终止它。关键在于：所有错误必须被捕获并通知页面，而非静默消失。
- 在 worker 脚本开头就注册全局错误处理器：
self.addEventListener('error', e => self.postMessage({ type: 'worker-error', error: e.message })) - 监听
port.onclose：每个页面连接时都绑定该事件，一旦 port 断开（Worker 退出或页面关闭），立即触发本地降级逻辑 - 页面收到
worker-error后，不重试连接 SharedWorker，而是直接 fallback 到 BroadcastChannel + 主从选举模式
页面不能依赖 Worker 永远在线，必须自带兜底通道
Shared Worker 的生命周期由“最后一个同源页面关闭”决定。若所有页面同时崩溃或强制刷新，Worker 会退出——这不是缺陷，而是规范行为。因此，页面自身必须保留最小可用通信能力。
- 初始化时同步检测：
if (typeof SharedWorker !== 'function') { useBroadcastFallback() }，不等连接失败再判断 - 即使 Worker 正常运行，也要用
localStorage.setItem('sw-last-active', Date.now())定期心跳；页面启动时检查该时间戳是否超 10 秒，超时即视作 Worker 不可用 - 业务消息发送前加双通道判断：优先走 Worker port，失败则自动切到 BroadcastChannel 广播，服务端无需区分来源
主控逻辑下沉到 Service Worker，Worker 只做代理
把连接管理、重连决策、心跳调度等高风险逻辑移出 Shared Worker，交给更稳定的 Service Worker —— 它在页面关闭后仍可运行数分钟，且支持 fetch 事件拦截和后台同步。
- Shared Worker 仅负责消息中转和端口路由，不做 new WebSocket、不存 ws 实例、不写 setInterval
- WebSocket 实际由 Service Worker 建立（通过
clients.matchAll()获取活跃页面后发起），并通过postMessage将连接状态广播给 Shared Worker 和各页面 - 页面与 Service Worker 通信走
navigator.serviceWorker.controller.postMessage()，比 SharedWorker 更健壮，且兼容性更好（Chrome/Firefox/Safari 全支持）
用 BroadcastChannel 做状态快照，不依赖 Worker 在线
Shared Worker 不在线时，页面间仍需感知基础状态（如“当前谁在管连接”“连接是否已断”）。BroadcastChannel 成为最轻量、最及时的状态广播层。
- 所有页面（包括 Worker）都监听同一频道：
new BroadcastChannel('app-state') - Service Worker 或主控页每次状态变更（open/closed/reconnecting）都广播一次，带版本号和时间戳
- 页面收到广播后更新本地缓存，并用
localStorage持久化最新状态，下次加载直接读取，不等待 Worker 启动
