broadcastchannel 同源判定严格逐字符比对协议、主机名、端口，故 localhost 与 127.0.0.1 被视为不同源而无法互通；需尽早初始化、主动同步状态、避免不可克隆数据、兼容降级并统一管理 close。
BroadcastChannel 能可靠同步同一站点下多标签页的消息，但必须满足“协议+域名+端口完全一致”，否则静默失效——连 error 都不抛，只收不到消息。
为什么 BroadcastChannel 在 localhost 和 127.0.0.1 下无法互通
浏览器把 http://localhost:3000 和 http://127.0.0.1:3000 当作两个不同源，哪怕内容一模一样。BroadcastChannel 的同源判定比 localStorage 更严格，它不走“主域宽松匹配”，而是逐字符比对协议、主机名、端口。常见踩坑点包括：
- 开发时混用
localhost和 IP 地址访问同一本地服务 - Vite/HMR 热更新临时启用了新端口（如
:3001），导致新标签页连的是另一个隐式隔离的频道 - Nginx 反向代理后端时未统一出口 Host 头，造成前端实际请求域名不一致
onmessage 监听不到第一条消息？执行时机很关键
如果页面加载后才创建 BroadcastChannel 实例，而另一标签页已提前发过消息，那这条消息就丢了——BroadcastChannel 不提供消息回溯机制。解决方案是尽早初始化，并主动“打招呼”：
- 在全局作用域（如模块顶层或
<script></script>开头）立即创建实例：const bc = new BroadcastChannel('my-app') - 页面就绪后立刻发一条上线通知：
bc.postMessage({ type: 'join', tabId: Math.random() }) - 监听方收到
join后，可主动拉取当前状态（比如从localStorage读表单数据），避免状态漂移
消息能发对象，但别直接传函数、DOM 节点或循环引用
postMessage() 底层用的是结构化克隆算法（structured clone），它支持 Date、RegExp、ArrayBuffer，但不支持：
- 函数、
undefined、Symbol、Promise - DOM 元素、
window、document - 含有循环引用的对象（如
obj.a = obj）
建议发送前做一次预检：try { JSON.parse(JSON.stringify(data)) } catch (e) { /* 不安全 */ }。虽然不是 100% 等价（比如会丢掉 Date 的类型），但能快速拦截大部分不可广播的数据。
Safari 15.4 之前不支持，且 error 事件必须监听
旧版 Safari（≤15.3）调用 new BroadcastChannel() 会直接抛 NotSupportedError；部分 Android WebView 也有类似问题。不能只靠 typeof BroadcastChannel !== 'undefined' 判断：
- 务必包裹
try/catch创建实例 - 始终绑定
bc.onerror = e => console.warn('BC error:', e)，某些环境（如 iOS 微信内置浏览器）会在非错误场景下也触发该事件 - 降级方案建议用
localStorage+storage事件兜底，虽然延迟高（约 100ms）、不保证顺序，但兼容性好
真正容易被忽略的不是怎么发消息，而是「谁来关」和「关不关得掉」：多个组件/模块都可能创建自己的 BroadcastChannel 实例，但 window.addEventListener('beforeunload', () => bc.close()) 只能覆盖一个。更稳妥的做法是在单例管理器里统一维护引用，并在所有相关生命周期钩子（如 Vue onBeforeUnmount、React useEffect cleanup）中调用 close()。否则标签页关了，channel 还挂在内存里，下次打开可能因残留监听导致重复响应。
