同源 iframe 间不能用 broadcastchannel 通信，因频道互不连通；首选 postmessage + 父页面中转，需校验 origin/source、防循环转发；contentwindow 直接调用风险高；localstorage 的 storage 事件 iframe 无法监听。
同源 iframe 之间不能直接用 BroadcastChannel 共享数据
因为每个 iframe 是独立的浏览上下文（browsing context），即使同源，BroadcastChannel 的频道作用域也只限于**当前页面的顶级窗口及其所有同源子页面（如新标签页、window.open 窗口）**，但不包括嵌套的 iframe。实测中，new BroadcastChannel('config') 在父页和子 iframe 中创建的是**互不连通的两个独立频道**——消息不会跨 iframe 边界传递。
同源 iframe 间通信首选 postMessage + 父页面中转
这是最可控、最易调试的方案：所有 iframe 都只跟父页面通信，由父页面统一分发。不需要额外服务端或共享域名，也不依赖浏览器新特性兼容性。
- 父页面监听所有 iframe 的
message事件，验证event.source是否为合法 iframe（比如检查event.source === iframe.contentWindow） - 父页面收到某 iframe 发来的数据后，遍历所有已加载的 iframe，调用
otherIframe.contentWindow.postMessage(data, origin)转发 - 每个 iframe 只需监听
window.addEventListener('message', ...)，且必须校验event.origin和event.source，防止被恶意窗口冒充 - 避免循环转发：父页面发给子 iframe 的消息，子 iframe 不应原样再发回父页面（可加
from: 'parent'字段标识来源）
contentWindow 直接调用仅适用于简单同步，且有严重时序风险
如果只是读写少量变量或触发函数，且能确保 iframe 已完全加载，可用 iframe.contentWindow 直接访问。但极易出错：
-
iframe.contentWindow在iframe.onload之前是null或未定义；用setTimeout轮询判断极不可靠 - 子 iframe 内部若执行了
document.write()或动态重载，会导致contentWindow引用失效 - 无法监听子 iframe 的异常或销毁，一旦引用断开，后续调用直接抛
DOMException: Blocked a frame from accessing a cross-origin frame（即使同源，某些重载场景也会临时触发该错误） - 若未来某天子 iframe 改为跨域，代码会静默失败，无降级提示
localStorage + storage 事件只在顶级窗口触发，iframe 无法监听
这是常被误解的一点：storage 事件**不会在 iframe 内触发**，哪怕它和父页同源。浏览器只在“顶级浏览上下文”（即 tab 标签页对应的主 window）上派发该事件。所以你在 iframe 里写 window.addEventListener('storage', ...) 是永远收不到父页修改 localStorage 的通知的。
真正可行的替代是：父页监听自身 storage 变化，然后主动用 postMessage 推送给各 iframe。但这就又回到了中转模式——不如一开始就把状态变更逻辑统一收口到父页。
复杂点在于：多个 iframe 可能同时修改同一份配置，父页需要做简单的冲突合并（比如按时间戳取最新值），而不是简单覆盖。这点容易被忽略，但线上出过因并发写入导致配置错乱的问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
