shared worker 与 broadcastchannel 应协同使用：前者作为状态中枢处理逻辑与任务分发，后者专注低延迟事件通知；组合可兼顾一致性、性能与响应速度。
Shared Worker 和 BroadcastChannel 都是浏览器中实现跨页面通信的机制，但它们定位不同、能力互补。单纯用 Shared Worker 处理大量广播消息容易成为瓶颈，而只靠 BroadcastChannel 又无法共享复杂状态或执行长期任务。真正提升通信效率的关键，不是二选一，而是让 Shared Worker 做“状态中枢 + 逻辑协调”，BroadcastChannel 做“轻量通知 + 即时同步”。
Shared Worker 负责状态管理与任务分发
Shared Worker 是一个独立于页面的脚本实例，多个页面可共用同一上下文。它适合维护全局状态（如用户登录态、配置、缓存数据）、执行耗时计算、或统一处理 API 请求。避免每个页面重复拉取或解析相同数据。
- 把 token 刷新、WebSocket 连接、本地缓存更新等逻辑集中到 Shared Worker 中，页面只通过
port.postMessage()发起请求，由 Worker 统一响应 - Worker 内部用 Map 或 WeakMap 管理各页面端口（
event.source），支持定向响应，而非全量广播 - 对高频写操作（如实时计数器）做节流或合并：例如 100ms 内收到 5 次 +1 请求，Worker 合并为 +5 后再广播结果
BroadcastChannel 专注低延迟事件通知
BroadcastChannel 基于事件机制，开销极小，适合触发 UI 更新、开关同步、路由跳转等不需要返回值的操作。它不经过 Worker 中转，天然更快，但不能传函数、不能保持连接、也不支持跨域（同源限制）。
- 当 Shared Worker 完成关键状态变更（如登录成功、配置加载完毕），立即通过
bc.postMessage({ type: 'auth:ready', user })通知所有页面 - 页面监听
bc.onmessage，收到后直接更新 React/Vue 的响应式状态，避免轮询或重复调用 Worker 接口 - 退出页面前发
{ type: 'page:leave', id }，Worker 可据此清理对应端口资源，防止内存泄漏
组合使用时的关键细节
两者协同不是简单叠加，需注意生命周期、错误隔离和降级策略。
- Shared Worker 启动失败（如不支持或被禁用）时，自动 fallback 到 BroadcastChannel + localStorage 监听（用
storage事件模拟状态同步） - 给每个 BroadcastChannel 实例加唯一名称（如
app-v2-state），避免与其他库冲突；Shared Worker 的 script URL 也建议带哈希后缀，确保更新后能正确重建 - 页面关闭时显式
port.close()并bc.close()，否则 Worker 可能持续持有已失效端口，影响后续通信 - 不要在 BroadcastChannel 中传大对象（>1MB），Chrome 会静默截断；敏感数据（如 token）绝不走 BroadcastChannel，只通过 Worker 的加密 port 通道传递
一个典型协作流程示例
用户在 A 页面修改主题色 → A 页面调用 worker.port.postMessage({ action: 'updateTheme', value: 'dark' }) → Shared Worker 更新内部状态，并调用 bc.postMessage({ type: 'theme:changed', value: 'dark' }) → B、C 页面监听到该消息，立即切换 CSS class → 同时 Worker 主动向 B、C 的 port 发送 { type: 'theme:synced' }，确认状态已就绪。
这样既保证了状态一致性（Worker 控制源头），又实现了 UI 响应速度（BroadcastChannel 零延迟触达），还保留了按需反馈的能力（port 通道双向通信）。
