前端 BroadcastChannel 多标签页状态同步：消息去重、版本冲突与关闭清理

运营同事把订单后台开成两个标签页：左边筛选“待退款”，右边刚改完日期范围，左边的列表却悄悄回到了旧条件。页面之间没有共享 JavaScript 变量，问题通常不在组件本身，而在“谁最后写入状态”没有规则。BroadcastChannel 可以让同源标签页互发消息，但它只负责传递，不负责去重、排序和关闭清理。同步层的这些边界，才是上线后最容易出问题的地方。

先把同步对象限制在真正需要跨页的状态

不要把整个 Redux、Pinia 或表单对象原样广播。适合跨标签页同步的通常是登录失效通知、筛选条件、草稿版本和主题设置；临时悬浮层、输入框光标、请求中的 loading 状态不值得广播。

下面用一个筛选状态说明协议。version 是发送方产生的单调递增数字，sender 用随机字符串区分标签页，sentAt 只用于排查日志，不拿它直接做严格排序。

const channelName = 'order-filter-sync';
const sender = crypto.randomUUID();
const channel = 'BroadcastChannel' in window
  ? new BroadcastChannel(channelName)
  : null;

let localVersion = 0;
let currentFilter = { status: 'refunding', from: '2026-08-01' };

function publishFilter(nextFilter) {
  localVersion += 1;
  currentFilter = nextFilter;
  channel?.postMessage({
    type: 'filter-change',
    sender,
    version: localVersion,
    sentAt: Date.now(),
    filter: nextFilter
  });
}

这里的关键不是 API 调用有多短，而是消息有明确的业务类型。以后还要同步“退出登录”或“草稿已保存”时，可以复用通道，但不要让接收端靠字段是否存在来猜消息含义。

接收端先去重，再决定是否覆盖当前状态

BroadcastChannel 不会把消息发回同一个发送者，但同一个页面可能因为组件重复挂载而注册多个监听器。工程上仍然要保留消息身份和最近处理记录，把“同一条消息不能处理两次”写成显式规则。

const seen = new Set();
let acceptedVersion = 0;

function messageKey(message) {
  return `${message.sender}:${message.version}`;
}

function acceptFilterMessage(message) {
  if (!message || message.type !== 'filter-change') return;
  if (message.sender === sender) return;

  const key = messageKey(message);
  if (seen.has(key)) return;
  seen.add(key);

  if (!Number.isInteger(message.version) || message.version  {
  acceptFilterMessage(event.data);
});

这段代码适合“一个页面先改，另一个页面跟随”的单写入者场景。注意版本号只在每个发送者自己的序列里递增；如果两个标签页都从 1 开始，单独比较数字会出现平局，不能把它当成完整的分布式时钟。

两个标签页同时修改时，版本冲突要有可见结果

最常见的错误是收到消息后无条件覆盖本地编辑。用户在 A 页刚选好“待退款”，B 页的旧筛选消息晚到一步，A 页就被改回“全部”。至少要先判断本地是否有未提交变更，再决定接受、合并还是提示用户。

如果业务需要严格的全局顺序，可以把消息改成带 updatedAt 和 tabId 的排序键，或者将最终状态放到服务端，由服务端返回权威版本。前端的 BroadcastChannel 更适合“通知其他页面重新读取”，不适合独自承担订单、库存这类关键数据的最终一致性。

关闭通道和降级路径要与主流程分开

组件卸载时移除监听器并关闭通道，否则单页应用切换路由几次后，旧组件仍可能响应消息。页面关闭前不必依赖 unload 广播“我走了”，因为浏览器可能直接终止页面；真正需要可靠保存的草稿，应在输入变化时写入服务端或 IndexedDB。

function disposeFilterSync() {
  channel?.removeEventListener('message', acceptFilterMessage);
  channel?.close();
}

function saveFilter(nextFilter) {
  currentFilter = nextFilter;
  localStorage.setItem('order-filter', JSON.stringify(nextFilter));
  publishFilter(nextFilter);
}

const initialFilter = channel
  ? currentFilter
  : JSON.parse(localStorage.getItem('order-filter') || 'null') || currentFilter;

降级到 localStorage 时要记住：它的 storage 事件只会在其他文档触发，当前页面不会收到自己的写入通知。若采用这个方案，仍需保留版本字段，并给 JSON 解析、字段缺失和旧数据格式加保护。

用三个检查确认同步层没有变成隐形覆盖器

验证不要只看“两个标签页都能变”。打开同源的 A、B 两页，按下面顺序操作：A 修改筛选，确认 B 只刷新一次；B 连续快速修改，确认 A 最终显示最新版本；A 输入未提交内容后让 B 修改，确认 A 出现冲突提示而不是被静默覆盖；最后刷新页面并关闭其中一页，确认没有重复监听和控制台异常。

如果业务状态包含敏感信息，消息里只发送“需要重新读取”的事件和资源标识，不要直接广播完整用户资料或访问令牌。BroadcastChannel 的边界是同源页面间通信，不是权限隔离层。

常见问题

BroadcastChannel 能跨域同步吗？

不能。它按源隔离，协议、域名和端口不同就不是同一个通道。跨域页面需要服务端中转或明确的窗口通信协议。

为什么消息没有发回当前标签页？

这是它的正常行为：发送者不会收到自己通过该通道发布的消息。当前页需要立即更新时，先更新本地状态，再广播给其他页面。

能用它同步订单最终状态吗？

不建议。它适合通知其他页面刷新；订单、库存和支付结果仍应以服务端权威版本为准，并处理网络失败和重复提交。

什么时候应该改用 WebSocket？

需要跨设备、跨用户或服务器主动推送时再考虑 WebSocket。仅仅是同一浏览器的几个标签页，不必为此引入长连接。

一个稳定的跨标签页同步层，核心不是把消息发出去，而是把消息身份、版本冲突、敏感状态和生命周期写清楚。先从“通知其他页面重新读取”这种低风险场景开始，再按业务一致性要求决定是否需要服务端版本。