前端跨标签页状态同步怎么选：BroadcastChannel、storage 事件与 SharedWorker 的边界

同一个后台系统开了两个标签页：一个页面退出登录，另一个页面却还显示“已登录”；或者编辑页保存草稿后，旁边的预览页迟迟不刷新。跨标签页同步没有一个万能 API，选型关键在于你要传的是“一条消息”、一个持久化值，还是一套由中心连接管理的状态。

一般的同源标签页通知优先选 BroadcastChannel；需要顺手留下最后状态时用 localStorage 配合 storage 事件；需要一个中心协调者或多个页面共享连接时，再考虑 SharedWorker。

先把同步任务拆成消息、状态和中心连接

“同步”至少有三种含义。用户在标签页 A 点了退出，标签页 B 只需知道发生了一个 logout 消息；用户在 A 选择了主题色，B 打开时还应该拿到最后一次值，这属于状态保存；如果多个页面还要共享一个长连接、统一排队或协调订阅，才是中心连接问题。

三个方案的消息路径并不相同

BroadcastChannel 的使用方式最直接：各标签页用同一个频道名创建对象，发送方调用 postMessage()，其他监听同频道的上下文收到 message。发送者自己的这个频道对象不会收到刚发出的消息，所以本地 UI 是否立即更新，要由发送代码显式完成。

storage 事件走的是另一条路径。标签页 A 写入 localStorage 后，同源的其他标签页才会收到事件；A 自己不会收到。这个差异很适合“写入值就是事实来源”的设置同步，但不适合把它当成可靠消息队列。

SharedWorker 则把页面接到一个共享 worker。每个页面通过 MessagePort 发消息，worker 在 connect 时保存端口并决定向哪些页面转发。多个页面必须共享完全相同的协议、主机和端口，不能把它当成跨源通信方案。

只做退出登录和刷新提示时，BroadcastChannel 更顺手

例如登录态由服务端 Cookie 管理，页面之间只需在退出后立即清理内存中的用户信息，可以把消息协议写得很小：

const channel = new BroadcastChannel('account-state');

channel.addEventListener('message', (event) => {
  if (event.data?.type === 'logout') {
    clearUserView();
    location.assign('/login');
  }
});

function logout() {
  clearUserView();
  channel.postMessage({ type: 'logout' });
  location.assign('/login');
}

window.addEventListener('pagehide', () => channel.close());

这里的 type 是业务协议的一部分，不能指望 API 自动理解消息含义。页面关闭时调用 close()，可以明确离开频道并让对象具备可回收条件。若新打开的标签页还要知道“刚才已经退出”，就要同时保留一个可读取的状态来源，不能只依赖广播瞬间。

需要恢复最后一次值时，用 localStorage 加 storage 事件

主题色、列表筛选条件、当前工作区这类值，通常应该在新标签页打开时可恢复。写入端保存 JSON，其他标签页监听同一个键：

const preferenceKey = 'workspace-preference';

function savePreference(preference) {
  localStorage.setItem(preferenceKey, JSON.stringify(preference));
  applyPreference(preference); // 当前标签页不会收到自己的 storage 事件
}

window.addEventListener('storage', (event) => {
  if (event.key !== preferenceKey || event.newValue === null) return;
  const preference = JSON.parse(event.newValue);
  applyPreference(preference);
});

const saved = localStorage.getItem(preferenceKey);
if (saved) applyPreference(JSON.parse(saved));

storage 事件包含 key、oldValue 和 newValue，但它不是一个带确认和重试的消息系统。连续写入同一个值时，还要考虑值是否真的发生变化；存储额度、隐私数据和清理策略也属于这个方案的责任范围。

多个页面需要一个协调者时再上 SharedWorker

SharedWorker 适合把共享状态或共享连接放在一个 worker 中，例如几个同源页面共同订阅一条数据流。页面端通过 port.postMessage() 发命令，worker 从 connect 事件拿到端口，再决定如何广播结果。这个结构多了一层生命周期管理，排查问题时也要同时看页面、端口和 worker。

不要为了“看起来更专业”把简单的退出通知塞进 SharedWorker。只有当多个页面确实需要共享连接、集中排队或由一个中间层维护状态时，它的额外复杂度才值得。

按边界做最后选择

可以用下面的判断收敛方案：消息不需要恢复，先用 BroadcastChannel；值需要被新页面读取，优先 localStorage 和 storage；需要共享连接或集中处理，再评估 SharedWorker。三者都不能替代服务端鉴权，客户端收到“退出”消息后仍要让服务端请求按真实会话状态拒绝。

常见问题

BroadcastChannel 能跨域同步吗？

不能按跨域通信来设计。它面向同源浏览上下文，而且还受到存储分区等浏览器边界影响；不同协议、主机或端口的页面不能直接共用一个业务频道。

storage 事件为什么在当前标签页没有触发？

这是它的定义：修改存储区域的文档不会收到这次事件，其他共享该存储区域的文档才会收到。因此当前页面要在写入后直接调用自己的状态更新函数。

SharedWorker 一定比 BroadcastChannel 快吗？

不能这样下结论。SharedWorker 解决的是共享 worker 和中心协调问题，不是简单的性能加速器；连接管理、兼容性和故障处理反而会增加成本。

上线前的最小验收清单

• 打开两个同源标签页，分别验证消息、状态恢复和页面刷新。
• 确认发送页是否需要本地立即更新，不把 BroadcastChannel 或 storage 事件当成回环通知。
• 把浏览器关闭、隐私模式、存储清理和不支持 SharedWorker 的情况纳入降级路径。
• 退出登录场景仍以服务端会话校验为准，跨标签页消息只负责及时刷新界面。

跨标签页同步的核心不是 API 数量，而是先确认“消息是否需要持久化”和“页面之间是否需要中心协调”。边界定清楚，代码通常只剩一个频道、一个键，或一组 MessagePort。