跨标签页通信方案汇总

同源多标签页之间要通信，可选方案有四种，差别在「是否持久化」「是否跨源」「是否需要服务端」。选错方案的典型后果是：要么为了一个简单通知引入了 Service Worker 的生命周期负担，要么用 storage 事件去传大对象把主线程拖慢。

一、BroadcastChannel 的适用面

同源页面之间最直接的方案：创建一个具名频道，任意页面 postMessage，其余页面都能收到。它简单、无需持久化、不依赖任何存储，适合「登录态变了」「主题切换了」这类瞬时通知。

// 登录态同步：一个标签页退出，其余标签页一起响应
const channel = new BroadcastChannel('auth')
channel.postMessage({ type: 'logout' })
channel.onmessage = (e) => {
  if (e.data.type === 'logout') redirectToLogin()
}

要注意的是它没有送达确认、没有持久性——页面刚打开时错过了消息就是错过了，需要状态同步的场景要配合一次主动拉取（比如进入页面先读一下当前登录态）。

二、storage 事件的限制

修改 localStorage 会触发其它同源标签页的 storage 事件，等于顺手利用了一层广播。它最大的优势是兼容性，几乎所有浏览器都支持。

// 写值触发其它标签页的 storage 事件
localStorage.setItem('theme', 'dark')
// 其它标签页监听（注意：本页面不会收到自己的写入）
window.addEventListener('storage', (e) => {
  if (e.key === 'theme') applyTheme(e.newValue)
})

三个代价要记牢：必须真的写值才触发；本页面不会收到自己触发的 storage 事件；写入大字符串有序列化开销，不适合传大对象。所以它适合「同步一个标志位 / 一个小状态」，不适合当消息总线。

三、SharedWorker 的重量

SharedWorker 被所有同源页面共享，是一个真正的「共有后台线程」——这正是它能做连接复用的原因。典型用法是让多个标签页只维持一个 WebSocket，消息汇总到 worker 再分发：

// 共享一个 WebSocket：多标签页只连一条，其余通过 worker 收消息
const worker = new SharedWorker('sync-worker.js')
worker.port.postMessage({ type: 'subscribe', channel: 'orders' })
worker.port.onmessage = (e) => updateOrders(e.data)

它适合做「连接复用」与「状态中心」，但调试麻烦（要在 DevTools 的应用面板里找 worker 实例），生命周期也比页面复杂。不是「能广播」就上它，而是「需要真正共享一份状态或一条连接」才上。

四、Service Worker 那条路

Service Worker 能触达所有受它控制的页面，甚至页面没打开时也能工作（配合推送）。语义上消息是先发给 SW，再由 SW 转发给各页面，所以引入了一层 SW 生命周期成本——注册、激活、更新，都要管。

// 发给 Service Worker，由它转发给受控页面
navigator.serviceWorker.controller?.postMessage({ type: 'refresh' })

它真正的价值是「离线标签页也要收到」——比如后台推送到达时，未打开的页面也要更新。如果不需要覆盖未打开的页面，这一层成本不值得。

方案可以降级使用，把差异收在一层里，业务代码不用关心走的是哪条：

const bus = 'BroadcastChannel' in window
  ? new BroadcastChannel('app')
  : {
      // 退回路：借 storage 事件，代价是要真的写一次值
      postMessage: (m) => localStorage.setItem('__bus', JSON.stringify({ ...m, t: Date.now() })),
    }

bus.postMessage({ type: 'logout' })

// 注意降级后本次页面收不到自己的消息，行为与 BroadcastChannel 不一致，要单独处理

五、按持久化与跨源需求选

按三个问题决策：要不要跨源（要就只能服务端或 postMessage）→ 离线标签页要不要收到（要就必须走 Service Worker）→ 要不要持久（要就用 localStorage 或 IndexedDB 存状态，而不是发消息）。多数业务其实只需要同源瞬时通知，BroadcastChannel 足够；storage 事件的优势是兼容性，代价是必须写值且本页不触发；需要连接复用才上 SharedWorker；需要覆盖未打开的页面才上 Service Worker。

需求	首选
同源瞬时通知	BroadcastChannel
兼容老浏览器	storage 事件
共享一条连接 / 状态	SharedWorker
离线页面也要收到	Service Worker
跨设备 / 跨用户	WebSocket + 服务端

多数业务 BroadcastChannel 就够，先回答三个问题再决定

图：跨标签页通信的决策路径——先回答三个问题，再选方案

六、几条容易被搞反的细节

storage 事件只发给其它同源页面，触发写入的那个页面自己收不到——需要本地也同步响应时，得手动再跑一遍同样的处理。

SharedWorker 与 Web Worker 的差别也在这里：后者每个页面各有一份，前者被所有同源页面共享，这正是它能复用连接的原因；页面全部关掉之后它才会被回收。

消息不保证送达：除 Service Worker 转发之外，多数方案对未打开或刚打开的页面都没有补发机制。需要状态同步时，「打开时主动拉一次」比指望消息必达更可靠。

BroadcastChannel 的适用场景与同源限制在 MDN 有说明，选方案前先确认覆盖范围。

一、BroadcastChannel 的适用面​

二、storage 事件的限制​

三、SharedWorker 的重量​

四、Service Worker 那条路​

五、按持久化与跨源需求选​