BroadcastChannel 实现同源多页广播需满足：同源、频道名严格一致且全局常量定义；避免重复 new 实例；消息须可结构化克隆且大小受限；新页面需发 join 消息主动拉取状态；必须显式 close() 防内存泄漏；不保证顺序与必达，关键逻辑需服务端校验。
能用 BroadcastChannel 实现实时广播，但必须满足同源（协议+域名+端口完全一致）、频道名严格一致、且每个页面都主动创建并监听——它不是自动同步状态的工具，而是“发一次、多端收”的广播机制。
频道名必须完全一致且全局定义
拼错一个字符，比如 'auth' 和 'Auth'，两个标签页就彻底失联。浏览器不报错，只静默丢弃消息。
- 所有页面统一用常量定义：
const CHANNEL_NAME = 'ui-sync';，然后都写new BroadcastChannel(CHANNEL_NAME) - 不要在函数里反复
new BroadcastChannel('ui-sync')——每次 new 都是新实例，监听器会叠加，导致同一消息被处理多次 - 子域名不算同源：
https://a.example.com和https://b.example.com无法通信；http://localhost:3000和http://localhost:8080也不行
消息必须可结构化克隆，且不能太大
postMessage() 底层走的是结构化克隆算法，不支持 function、undefined、Symbol、Promise 或循环引用对象。传了会直接抛 DataCloneError，Chrome 限制约 1MB，Firefox 更严（约 64KB）。
- 发送前建议预检：
try { JSON.parse(JSON.stringify(data)) } catch (e) { /* 不可广播 */ } - 别传
event对象、Vue 组件实例或 React state——它们含大量不可克隆属性 - 大状态（如整个 store）只传
{ type: 'STATE_UPDATE', key: 'cart' }，接收方再自己拉取
监听前先发「上线通知」，否则新标签页收不到历史状态
刚打开的标签页不会收到之前已发出的消息，所以仅靠监听 message 事件会导致状态不同步。典型表现：A 标签页已登出，B 标签页刚打开，仍显示“已登录”。
立即学习“前端免费学习笔记（深入）”；
- 页面加载完成、
BroadcastChannel实例创建后，立刻发一条上线消息：bc.postMessage({ type: 'join', timestamp: Date.now() }) - 接收方监听到
type: 'join'时，主动触发一次状态拉取（例如调用fetch('/api/user')），而不是等下一条业务消息 - 避免用
localStorage+storage事件降级——容易和BroadcastChannel形成循环触发
必须显式调用 close()，否则内存泄漏风险真实存在
忘记 bc.close() 不只是浪费内存。在 Safari 和旧版 Edge 中，页面卸载后 channel 实例可能仍驻留，后续再创建同名 channel 会触发 InvalidStateError 或静默失败。
- 在
beforeunload事件中调用：window.addEventListener('beforeunload', () => bc.close()) - Vue/React 项目中，在组件
onUnmounted或useEffect清理函数里调用bc.close() - 不要依赖浏览器自动清理——它不可靠，尤其在 SPA 页面反复切换时
最易被忽略的一点：它不保证消息顺序，也不保证 100% 送达。UI 同步类场景可以接受偶尔丢失，但关键逻辑（如支付确认、权限变更）必须搭配服务端校验或 WebSocket 回执机制。
