BroadcastChannel 原生跨 Tab 通信实战：别再用 localStorage 监听

用户在浏览器里同时打开好几个标签页，一处退出登录、改动购物车或切换全局深色模式，其他页面往往需要立刻同步。怎么实现这类跨标签页联动？

以往最顺手也最常见的做法，就是借道 localStorage：在一个 Tab 里写入一笔临时标记，然后让其他 Tab 监听 window.addEventListener('storage', ...) 事件。

这套写法虽然能把业务跑通，但用多了就会发现它其实挺别扭。localStorage 本质上是同步磁盘存储，每次写入都要走一遍磁盘 I/O，高频消息下不仅容易卡主线程，而且还有 5MB 的容量限制，传复杂对象还得反复写 JSON.stringify 和 JSON.parse。

其实对于同源页面之间的消息同步，现代浏览器早就已经标配了一个原生纯内存通道：BroadcastChannel API。

纯内存广播与结构化克隆

相比于借道磁盘读写的 localStorage，BroadcastChannel 是浏览器专门为同源环境提供的一套纯内存广播机制。

在性能方面，所有消息分发都直接在浏览器内存里流转，消息从发送方发出到各个接收页面触发回调，耗时通常都在 1 毫秒以内。这不仅完全没有磁盘读写和存储配额的包袱，也直接避开了多标签页并发写磁盘时可能出现的锁竞争问题。

在数据传递上，BroadcastChannel 底层直接支持结构化克隆算法（Structured Clone Algorithm）。我们不再需要像以前那样手动序列化字符串，像 Date、Map、Set、ArrayBuffer、TypedArray 甚至 Blob 这类复杂数据结构，都可以直接放进消息对象里发过去，接收方拿到的就是还原好的原生对象。

另外在通信范围上，它不仅能在普通浏览器 Tab 和 Window 之间发消息，还能直接连通 Web Worker、Service Worker 以及同源 iframe，把同源环境下的各个上下文串联起来。

// 1. 创建同名广播频道（同源下共享）
const authChannel = new BroadcastChannel('app_auth_bus');

// 2. 发送方：用户在任意 Tab 登出时广播结构化数据
function handleUserLogout() {
  authChannel.postMessage({
    type: 'LOGOUT',
    timestamp: new Date(),
    reason: 'USER_INITIATED',
    clearedKeys: ['token', 'user_session']
  });
}

// 3. 接收方：其他所有同源页面即时响应
authChannel.onmessage = (event) => {
  const { type, timestamp, reason } = event.data;
  if (type === 'LOGOUT') {
    console.log(`收到登出事件，触发时间: ${timestamp.toISOString()}`);
    // 立即就地重置前端状态与路由跳转
    resetUserStore();
    window.location.replace('/login');
  }
};

// 4. 组件销毁或页面卸载时优雅关闭
function cleanup() {
  authChannel.close();
}

适合拿来解决什么问题

在实际业务场景里，有几类交互用 BroadcastChannel 来处理会非常顺手。

比如最常见的音视频与长连接抢占。如果用户同时打开了几个视频详情页，在 Tab A 点击播放的时候，我们就能通过频道向其他 Tab 广播一条暂停指令，防止两个页面同时出声。再比如，在多标签页场景下，我们可以只选出一个主 Tab 去维持 WebSocket 长连接，其他 Tab 都通过 BroadcastChannel 来共享接收到的消息流，这样就能明显减少服务端的连接开销。

再比如购物车与表单数据的本地同步。当用户在某一个标签页里调整了商品数量或者勾选了优惠券，我们直接把更新后的状态通过频道广播出去，其他已经打开的页面收到后就能就地更新本地状态，根本不需要再去挨个请求后端的刷新接口。

如果是在做大屏数据可视化或者多窗口协同编辑，因为通道支持直接传递二进制的 ArrayBuffer 数据，我们还可以用它来实时同步各窗口的画布坐标和渲染状态，整体延迟非常低，配合起来基本没有肉眼可见的卡顿。

什么时候不能单靠它

不过在使用的时候，也有两个很关键的技术边界得提前想清楚。

首先是同源策略的限制。BroadcastChannel 严格遵循同源策略，不同域名、不同子域或者不同端口之间都没法直接接收到广播。如果项目里确实有跨子域通信的需求，那还是得老老实实通过同源 iframe 代理加上 window.postMessage 来做消息转发。

另外就是它的非持久化特性。广播通道里的消息属于即发即收的纯内存流转，如果某个页面在消息派发时还没被创建或打开，后续进入时肯定读不到之前的历史消息。所以要是遇到既需要跨页面即时响应，同时又需要持久保存历史状态的场景，通常比较稳妥的做法是采用“IndexedDB 负责数据存储 + BroadcastChannel 负责派发实时变更通知”的组合，把数据存储与事件通知的职责彻底拆开。

只要是在同源环境下做多页面的即时联动，直接用 BroadcastChannel 来收发消息就已经足够好用了，完全用不着再去折腾 localStorage 那些间接的监听逻辑了。