Web Worker 不能直接使用 BroadcastChannel，因其构造函数在 Worker 中被禁用；需主线程通过 BroadcastChannel 协调多标签页，由 SharedWorker 承担离线计算与状态同步。
不能直接用 BroadcastChannel 在 Web Worker 中发起广播，但可以和主线程协作，让 Worker 承担计算，主线程负责跨标签页调度与状态同步——这才是可行的“多标签共享离线计算”路径。
为什么 Web Worker 不能直接用 BroadcastChannel
BroadcastChannel 构造函数在 Web Worker 环境中被浏览器明确禁用（调用会抛 ReferenceError: BroadcastChannel is not defined）。这是设计使然：BroadcastChannel 是为同源页面上下文（window、iframe）间广播设计的，而 Worker 运行在独立线程，无 DOM 上下文，也不参与页面生命周期广播域。所以Worker 无法自己创建频道、发送或监听广播消息。
正确协作模式：主线程调度 + Worker 计算
把任务拆成两层：主线程管“谁来算、算什么、结果发给谁”，Worker 管“纯计算、不碰通信”。所有标签页共用同一个 SharedWorker（或通过 BroadcastChannel 协商由一个 tab 启动专用 Worker），避免重复加载与资源浪费。
- 每个标签页启动时，先通过 BroadcastChannel 广播注册请求，例如：
{ type: "register", tabId: "tab_abc123" } - 所有标签页监听该频道，维护一份活跃 tab 列表；按字典序选出首个 tab 作为“协调者”（类似 Master 选举）
- 协调者 tab 负责创建并复用一个 SharedWorker（或通过
navigator.serviceWorker.ready检查后使用 Service Worker 做中转），其他 tab 通过postMessage向该 Worker 提交计算任务 - Worker 接收多个 tab 的任务后，可排队、去重、合并或优先级调度（如用
setTimeout或queueMicrotask控制执行节奏），完成后将结果postMessage回原调用 tab（需附带taskId或tabId）
离线能力的关键支撑点
真正实现“离线计算”的不是 BroadcastChannel，而是 Worker 自身的运行特性：
- SharedWorker 在所有同源页面关闭后仍可驻留（只要没被系统回收），能继续执行长时间任务
- 计算过程不依赖网络，输入数据由主线程传入（结构化克隆），输出也通过
postMessage返回 - 若需持久化中间状态，可在 Worker 内部调用 IndexedDB（Worker 支持），避免页面刷新丢失进度
- 主线程可用 localStorage 记录任务元信息（如
pending_task_ids），页面重开后主动向 Worker 查询未完成项
实际任务分发与结果同步示例
比如多个标签页同时触发“批量图片灰度处理”：
- 用户在 tab A 点击处理 100 张图 → A 生成 taskId = "gray_001"，通过 BroadcastChannel 广播：
{ type: "task-assign", taskId: "gray_001", tabId: "tab_a", count: 100 } - 所有 tab 收到后更新本地待处理队列；协调者 tab 发送
{ cmd: "start", taskId: "gray_001", images: [...] }给 SharedWorker - Worker 分片处理，每完成 10 张就
postMessage({ taskId: "gray_001", progress: 10 })给 A - A 收到后更新 UI；若 A 关闭，B 可从 localStorage 读到 "gray_001" 未完成，主动向 Worker 查询当前进度并接管后续通知
