使用 BroadcastChannel 实现浏览器标签页同步

BroadcastChannel API 是浏览器原生的消息总线，允许同源的标签页、窗口、iframe 和 Worker 之间进行实时通信——它是专为解决多标签页状态漂移问题而生的方案。所谓状态漂移，是指在一个标签页中退出登录后，其他标签页仍然显示已登录的界面。这套 API 只需四个调用，无需服务器、无需握手、无需任何依赖。本文将介绍其最简 API 用法、可扩展的动作类型消息模式、框架集成时的正确清理方式、容易被忽视的注意事项，以及当前浏览器支持情况和可运行的降级方案。

什么是多标签页状态漂移？

多标签页状态漂移是指同一应用的两个已打开标签页持有不一致状态的一类 Bug：你在一个标签页中退出登录，另一个标签页仍然渲染着仪表盘；或者你在一个标签页中清空了购物车，另一个标签页仍然显示着商品。对这类操作流程的会话回放往往能直观呈现问题症状——用户在已于其他标签页清空的购物车中提交订单，或在本应退出登录的标签页中继续操作——而 BroadcastChannel 正是为消除这种状态不同步而生的。

开发者通常会用三种次优方案来修补这个问题。localStorage 的 storage 事件可以跨标签页触发，但只能传递字符串，每条消息都需要序列化和反序列化，还要进行繁琐的键值管理。定时轮询服务器或 localStorage 既浪费资源又存在延迟——大多数时候检查结果都是”无变化”。SharedWorker 和 WebSocket 是真正有效的工具，但对于同一台机器上两个标签页之间的同步，让消息经由服务器进行 Socket 往返通信实在过于繁重。

BroadcastChannel API 的四个调用

整套 API 只有四个调用，任何使用相同名称构建频道的上下文都会加入同一条消息总线。你只需连接、监听、发送和关闭：

const channel = new BroadcastChannel("app-sync");

channel.onmessage = (event) => {
  console.log("Received:", event.data);
};

channel.postMessage({ hello: "world" });

channel.close(); // 在卸载/销毁时调用

载荷类型是其核心优势。通过 postMessage 发送的数据使用结构化克隆算法进行序列化，因此你可以直接传递对象、数组、Map、Set 和 Blob，无需字符串化——接收方直接从 event.data 中读取到一个完整的对象。Symbol 和 SharedArrayBuffer 是无法被克隆的两个显著例外。频道仅限同源使用，并且每个上下文应复用同一个频道实例：在每次发送时都构造一个新的 BroadcastChannel 会导致监听器泄漏。

如何组织 BroadcastChannel 消息的结构？

可扩展的消息模式是使用可辨识消息——{ type, payload }——配合一个监听器，根据 type 进行分支处理并将每个动作应用到本地状态。这样可以确保所有上下文遵循同一套协议；API 本身不为消息赋予任何含义，因此需要由你来定义。

const channel = new BroadcastChannel("cart-sync");
let cart = [];

channel.onmessage = ({ data }) => {
  if (data.type === "ADD_ITEM") cart.push(data.payload);
  else if (data.type === "CLEAR") cart = [];
  render();
};

function addItem(item) {
  cart.push(item);       // 立即更新当前标签页
  render();
  channel.postMessage({ type: "ADD_ITEM", payload: item });
}

注意，发送方在广播之前直接更新自身状态——由于标签页不会收到自己发出的消息，你需要内联应用本地变更，然后让广播扩散到其他所有标签页。

跨标签页同步认证状态、购物车和设置

最具价值的使用场景包括：会话同步（退出登录的广播清除所有标签页的状态）、购物车/设置/主题同步，以及多标签页表单自动填充。在 React 中，应在 useEffect 内创建频道，并在返回的清理函数中调用 close()；若不执行清理，每次重新挂载都会泄漏一个活跃的监听器。

import { useEffect } from "react";

function useAuthSync(onLogout) {
  useEffect(() => {
    const channel = new BroadcastChannel("auth");
    channel.onmessage = ({ data }) => {
      if (data.type === "LOGOUT") onLogout();
    };
    return () => channel.close();
  }, [onLogout]);
}

// 退出登录时：清除本地会话，然后
// new BroadcastChannel("auth").postMessage({ type: "LOGOUT" })

在 Svelte 5（runes 模式）中，将频道封装在 store 中。有一点需要注意：postMessage 需要接收普通的可克隆值，而非响应式代理，因此在广播前应通过 $state.snapshot 传递值——代理对象会导致结构化克隆步骤失败。

// theme.svelte.js — Svelte 5 (runes)
export class ThemeStore {
  value = $state("light");
  #channel = new BroadcastChannel("theme");
  constructor() {
    this.#channel.onmessage = ({ data }) => { this.value = data; };
  }
  set(next) {
    this.value = next;
    this.#channel.postMessage($state.snapshot(next));
  }
}

大多数教程忽略的注意事项

有四种行为容易导致实现出错，而大多数文章对此都避而不谈：

• 标签页无法收到自身发出的广播。 消息会触发到所有监听该频道的对象，唯独不包括发送消息的那个对象——这是规范规定的行为，并且是有益的：它避免了你原本需要通过自身 ID 检查来防范的无限反馈循环。发送方的状态变更应内联应用。
• “同源”实际上是”同一存储分区”。 存储分区按顶级站点划分，因此即使在同一源下，跨站 iframe 也无法与顶级页面共享频道，且频道永远无法跨越不同子域。
• 它是管道，而非存储桶。 BroadcastChannel 只负责传输消息，不存储任何内容。需要将其与 localStorage 或 IndexedDB 配合使用，既用于持久化，也用于为事件触发后才打开的标签页提供初始状态——晚打开的标签页从未收到过该广播，应在挂载时从持久化存储中读取状态。
• 务必在卸载时调用 close()。 关闭操作会断开对象连接并释放其以供垃圾回收；如果每次创建频道后不调用 close()，每次重新挂载都会泄漏一个监听器。

浏览器支持情况与特性检测降级方案

BroadcastChannel 已成为基线标准，自 2022 年 3 月起广泛可用，当前版本的 Safari 已完全支持——“WebKit 不支持”的说法早已过时，在 Safari 15.4 之前才成立。根据 caniuse 和 Chrome for Developers 博客，最低版本要求为：Chrome 54+、Edge 79+、Firefox 38+、Safari 15.4+（macOS 和 iOS）、Opera 41+、Samsung Internet 7.2+；仅 Internet Explorer 从未支持该 API。

对于 2022 年之前的浏览器，可通过 'BroadcastChannel' in window 进行特性检测，并降级使用基于 storage 事件、暴露相同接口的 shim：

function createChannel(name) {
  if ("BroadcastChannel" in window) return new BroadcastChannel(name);
  // 降级方案：使用 localStorage 的 "storage" 事件（仅支持字符串）
  return {
    postMessage: (data) =>
      localStorage.setItem(name, JSON.stringify({ data, t: Date.now() })),
    set onmessage(fn) {
      window.addEventListener("storage", (e) => {
        if (e.key === name && e.newValue) fn({ data: JSON.parse(e.newValue).data });
      });
    },
    close() {},
  };
}

优先使用原生 API，将 shim 作为兜底保障。在所有现代浏览器上，BroadcastChannel 已经开箱即用——选定一个频道名称，统一采用 { type, payload } 格式，将需要在完全关闭后仍能保留的状态持久化，你应用中潜藏的过期标签页问题便会迎刃而解。

常见问题

BroadcastChannel 能跨不同子域使用吗？

不能。BroadcastChannel 的作用域限定在同一存储分区，而非仅限于同一源，且永远无法跨越不同子域。app.example.com 上的页面与 account.example.com 上的页面无法共享频道。即使在同一源下，跨站 iframe 也无法与顶级页面共享频道，因为存储分区是按顶级站点划分的。如需跨子域同步，请使用服务器或 WebSocket。

BroadcastChannel 与 storage 事件在跨标签页同步方面有何区别？

BroadcastChannel 可直接传输结构化克隆载荷，例如对象、Map、Set 和 Blob，但不存储任何内容。localStorage 的 storage 事件只能传递字符串，强制你对每条消息进行序列化和反序列化，但其副作用是写入了持久化状态。需要传输丰富数据类型的消息驱动同步时，使用 BroadcastChannel；同时需要持久化，或需要为事件触发后才打开的标签页提供初始状态时，将其与 localStorage 或 IndexedDB 配合使用。

发送 BroadcastChannel 消息的标签页会收到自己发出的消息吗？

不会。根据规范，消息会触发到所有监听该频道的 BroadcastChannel 对象，唯独不包括发送消息的那个对象。标签页永远不会收到自身发出的广播，这从根本上避免了你原本需要通过自身 ID 检查来防范的无限反馈循环。正因如此，应在调用 postMessage 之前内联应用发送方自身的状态变更，然后让广播扩散到所有其他上下文。

如果所有标签页都关闭了，BroadcastChannel 消息会怎样？

消息将会丢失。BroadcastChannel 是管道，而非存储桶：它只负责传输消息，不存储任何内容，因此在没有其他标签页监听时广播的任何状态，在所有实例关闭后都将消失。在事件触发后才打开的标签页永远不会收到原始消息。为了在这种情况下保留状态，应将状态持久化到 localStorage 或 IndexedDB，并在挂载时从该存储中为晚打开的标签页恢复状态，而不是单纯依赖频道。