BroadcastChannel 多标签同步时如何忽略自己发出的消息

BroadcastChannel 设计上就是把消息发给同源的其他浏览上下文；同一个 BroadcastChannel 对象调用 postMessage() 后，不会再收到自己的 message 事件。因此只有一个 channel 实例时，不需要额外写“忽略自己”的判断。

真正容易出问题的是同一页面创建了两个同名实例，或业务层又包了一层事件转发。此时应给每个页面上下文生成一个 senderId，把它放进消息体，接收端先比较发送者再更新状态。这样过滤的是“来源”，不会误伤内容相同但确实来自其他标签的消息。

先判断你遇到的是哪一种“自己”

“自己发出的消息”有两种含义。第一种是当前变量 channel 调用 postMessage() 后，期待同一个对象的监听器也收到事件；这种期待不成立。第二种是同一个标签页里创建了 channelA 和 channelB，它们订阅相同的频道名。这两个对象属于不同的监听对象，业务上就可能把其中一个实例发出的消息看成当前页面自己的更新。

用 senderId 在消息入口做过滤

把身份放在协议元数据中，业务数据放在 payload 中。不要拿主题、时间戳或对象内容猜来源，因为不同标签可能恰好发送相同的数据。

const channel = new BroadcastChannel("app-sync");
const senderId = crypto.randomUUID(); // 每个页面上下文生成独有身份

function publish(type, payload) {
  channel.postMessage({
    type,
    senderId,
    payload,
    sentAt: Date.now(), // 仅用于诊断，不用它判断来源
  });
}

channel.addEventListener("message", ({ data }) => {
  // 先挡掉当前上下文发出的消息，再进入业务分支
  if (!data || data.senderId === senderId) return;

  if (data.type === "theme:changed") {
    applyTheme(data.payload); // 这里只处理其他上下文的变更
  }
});

window.addEventListener("pagehide", () => {
  channel.close(); // 页面离开时释放监听对象
});

这里的 senderId 只在当前页面生命周期内有效即可。刷新页面后生成新值，不影响其他标签；如果把它放进 localStorage，多个标签反而会共享同一个身份，过滤逻辑就失去意义。

多标签和多实例要保持同一套协议

发送端不需要知道有多少标签在监听，接收端也不应依据标签标题、URL 或打开顺序判断来源。所有监听者都按同一协议检查 senderId，然后再检查 type 和业务字段。这样新增 iframe、Worker 或第二个模块实例时，边界仍然清楚。

function isExternalMessage(data) {
  // 协议字段不完整时直接丢弃，避免异常数据进入状态层
  return data && typeof data === "object"
    && typeof data.senderId === "string"
    && data.senderId !== senderId;
}

channel.onmessage = (event) => {
  if (!isExternalMessage(event.data)) return;
  // 通过 type 分流，避免把其他业务消息当成同步事件
  if (event.data.type !== "theme:changed") return;
  applyTheme(event.data.payload);
};

关闭和异常边界不能省略

BroadcastChannel 传递的是结构化克隆数据，不能把函数、DOM 节点等不可克隆对象放进消息。频道已经 close() 后再次发送会抛出 InvalidStateError，所以页面离开时关闭，并让发送入口掌握好对象生命周期。若发送内容无法克隆，接收端不会得到正常业务消息，应在开发阶段检查 messageerror。

还要记住它不是跨站广播：通信要求同源，并受浏览器存储分区约束。只要问题不是“我收到了自己的消息”，而是“两个标签状态没有同步”，优先检查频道名、来源分区和监听对象是否仍然存活。

常见问题

为什么我只创建一个 channel 仍然看到了重复更新？

重复可能来自业务函数被调用两次、页面注册了两次监听器，或另一个封装实例使用了相同频道名。先打印实例创建位置，再用 senderId 和事件类型记录来源。

senderId 应该放在哪一层？

放在消息协议的元数据层最合适，例如和 type、sentAt 同级；不要混进主题对象，避免业务代码为了判断来源而依赖业务字段。

可以用标签页的 URL 判断是不是自己吗？

不建议。多个标签通常拥有相同 URL，刷新后 URL 也不会表达页面实例身份。运行时随机 ID 更直接，也不暴露业务标识。