broadcastchannel 实现多标签页实时同步需满足同源、同名频道、及时关闭三条件：必须协议+域名+端口完全一致；所有页面用完全相同字符串（如'auth'）初始化；页面卸载前须调用bc.close()防内存泄漏和错误。
BroadcastChannel 能做到多标签页实时通知同步，但必须满足同源、正确初始化、及时关闭三个硬条件，缺一不可。
同一源下 channel name 必须完全一致且全局唯一
多个标签页只有用new BroadcastChannel('auth')中完全相同的字符串（包括大小写、空格、下划线），才能加入同一个广播组。拼错一个字符，比如'Auth'或'auth-v2'，就收不到彼此消息。
- 推荐在模块顶层定义常量：
const CHANNEL_NAME = 'auth';，所有页面都引用它 - 不要在函数里反复
new BroadcastChannel('auth')——每次 new 都是新实例，会累积监听器、导致重复响应甚至内存泄漏 - iframe 也要显式创建同名 channel 才能参与通信；若 iframe 被 sandbox 属性限制（如缺少
allow-scripts），则 channel 创建失败或静默不工作
监听前先发「上线通知」避免状态不同步
后打开的标签页无法收到之前已发出的消息，所以仅靠被动监听会丢失初始状态。常见表现是：B 标签页刚打开，A 标签页已登出，但 B 仍显示“已登录”。
- 页面加载完成、channel 创建后立即发一条上线消息：
bc.postMessage({ type: 'join', timestamp: Date.now() }) - 接收方收到
type: 'join'时，主动触发一次状态拉取（例如调用fetch('/api/user')），而不是等下一条业务消息 - 避免用
localStorage+storage事件降级——容易和 BroadcastChannel 形成循环：A 写 storage → B 监听并 postMessage → B 又写 storage → A 再触发…
消息内容必须可结构化克隆且控制大小
postMessage()底层走的是结构化克隆算法，不支持function、undefined、Symbol、Promise、循环引用，也不加密、不鉴权。
- 发送前建议预检：
try { JSON.parse(JSON.stringify(data)) } catch (e) { /* 不可广播 */ } - 敏感字段（如 token）别直接传，只传
{ type: 'logout', userId: '123' }这类标识，业务逻辑由接收方自行校验 - Chrome 中单条消息超 ~1MB 会抛
DataCloneError，Firefox 更严（约 64KB），大状态同步只传 key 或 diff，再由接收方主动拉取 - 绝对不要传
event对象、Vue 组件实例、React state 对象——它们含大量不可克隆属性
务必显式 close() 且防自收、防卸载丢失
忘记close()不是小问题：页面卸载后 channel 实例可能仍驻留内存，在 Safari 和旧版 Edge 中引发InvalidStateError或静默失败。
- Vue/React 中应在组件卸载钩子（如
onUnmounted或useEffect(() => () => bc.close(), [])）里调用bc.close() - 监听回调里加守卫：
if (event.source === self) return;——虽然规范说不应自收，但 Chrome 旧版本存在例外 - 监听函数内避免耗时操作（如同步 DOM 更新、复杂计算），否则会阻塞后续消息处理，造成延迟或丢消息
- 隐私模式（如 Safari 无痕窗口）可能默认禁用 BroadcastChannel，需有降级兜底（如轮询 +
visibilitychange检测）
真正难的不是发消息，而是让每个标签页在任意时刻（刚打开、切回来、正在编辑表单）都能做出合理响应——这要求你把「广播」当成信号，而不是命令；状态决策始终由本地逻辑完成，而不是盲目信任收到的每一条消息。
