BroadcastChannel 与 SharedWorker 本质不互通，因通信链路断裂、生命周期错位、跨源限制三重问题；SharedWorker 默认不监听 BroadcastChannel 的 message 事件，需自行创建同名通道并转发消息。
BroadcastChannel 和 SharedWorker 本质不互通，强行“配合”会掉进通信链路断裂、生命周期错位、跨源限制三重坑里——别这么干。
为什么 BroadcastChannel.postMessage() 发不到 SharedWorker
BroadcastChannel 只能向同源、同 name 的 Window、Worker（含 ServiceWorker）、SharedWorker 实例广播，但 SharedWorker 的全局作用域（self）**默认不监听 message 事件以外的通道消息**。它收不到 BroadcastChannel 的事件，因为：
-
BroadcastChannel发送的是message事件，但触发在self上，而SharedWorker的主入口脚本需显式调用self.addEventListener('message', ...)才能接收 —— 这个message是来自页面的port.postMessage()，不是BroadcastChannel -
BroadcastChannel的事件对象类型是MessageEvent，但它的source是null，无法被SharedWorker的port关联或响应 - 实测中，即使在
SharedWorker中new BroadcastChannel('xxx')并addEventListener('message', ...)，也收不到其他 tab 发来的消息 —— 因为各BroadcastChannel实例彼此隔离，不共享事件循环
想让 SharedWorker 当“中心”，得换通信路径
真正可行的方案是：所有页面通过 SharedWorker 的 port 发送消息，由 SharedWorker 统一处理并用 BroadcastChannel 向全站广播；反过来，若某页要用 BroadcastChannel 主动推，SharedWorker 必须自己也创建同名 BroadcastChannel 并监听，再把消息转发到各 port。关键点：
- 每个页面必须先
const sw = new SharedWorker(...)，再sw.port.start()，否则port不激活 -
SharedWorker内部要同时维护两个通信端：一个BroadcastChannel('my-channel')（用于接收广播），一个Map存所有连接的port（用于反向分发） -
BroadcastChannel的postMessage()不能传function、DOM节点、undefined或带循环引用的对象；建议只传 plain object +ArrayBuffer/Transferable - 如果页面关闭但没
port.close()，SharedWorker的port会滞留，需监听port.onclose清理
示例片段（SharedWorker 主脚本）：
const bc = new BroadcastChannel('app-bus');
const ports = new Map();
self.addEventListener('connect', e => {
const port = e.ports[0];
const id = crypto.randomUUID();
ports.set(id, port);
port.start();
port.onmessage = ({ data }) => {
// 页面主动发给 SharedWorker 的指令
if (data.type === 'broadcast') {
bc.postMessage({ from: id, payload: data.payload });
}
};
port.onclose = () => ports.delete(id);
});
bc.addEventListener('message', e => {
// 收到广播，转发给所有活跃 port
ports.forEach(port => port.postMessage(e.data));
});
兼容性与降级必须考虑的硬伤
BroadcastChannel 在 Safari 15.4+ 才支持 SharedWorker 实例监听（此前仅限 Window），且 iOS Safari 完全不支持 SharedWorker；SharedWorker 本身在 Firefox 中默认禁用（需 dom.serviceWorkers.enabled 开启），Edge 105+ 才稳定。这意味着：
- 不能假设
SharedWorker一定存在，需用if (typeof SharedWorker !== 'undefined')包裹初始化逻辑 - 一旦降级，只能 fallback 到
localStorage+storage事件（延迟高、不支持二进制、无顺序保证），或直接用多个BroadcastChannel实例各自广播（失去“中心”调度能力） -
BroadcastChannel的close()必须显式调用，否则可能泄漏内存；尤其在 SPA 路由切换时，容易忘记清理旧 channel 实例
真正可靠的“全站消息中心”目前只有 ServiceWorker + clients.matchAll() + postMessage() 这一条路；SharedWorker 的定位是多页面共享状态和轻量计算，不是通信枢纽。把广播逻辑塞进它里面，等于让快递员兼做调度中心和分拣线——活能干，但一出错就全瘫。
