不能依赖name或id做跨源通信标识，因window.frames["name"]跨源返回undefined、window.name可被任意覆盖、同名iframe/window导致引用错乱；唯一可靠的是contentWindow/opener引用加targetOrigin校验。
HTML 多窗口通信中，不能依赖 name 或 id 作为跨源通信的标识依据；唯一可信赖的结构化标识是显式绑定的 window 引用 + postMessage 的 targetOrigin 校验。
为什么不能用 frame name 或 window.name 做通信标识
虽然 或 window.name = "popup" 看似能标识窗口，但它们在跨源场景下完全失效：
-
window.frames["sidebar"]在目标页面不同源时返回undefined，读取失败 -
window.name是可被任意脚本覆盖的字符串，无来源约束，无法用于安全消息路由 - 多个同名
或重复打开的window.open会导致name冲突，引用错乱 - 现代浏览器对
frameset已废弃（HTML5 不再支持），name属性在新上下文中语义弱化
真正可用的结构化标识：contentWindow 和 opener 引用
通信前必须拿到对方窗口的 Window 对象引用，这是所有后续操作的基础：
- 对于
：等load事件后取iframeEl.contentWindow，否则为null - 对于
window.open()：检查返回值是否为null（弹窗被拦截），非空才可存为popupWin - 子窗口访问父窗口：用
window.opener（仅限未被noopener修饰） - 嵌套 iframe 场景中，若父页加了
sandbox="allow-scripts"但没加allow-same-origin，contentWindow仍不可访问，只能靠postMessage单向发
targetOrigin 必须写死，不能用 * 代替域名
postMessage(data, targetOrigin) 中的 targetOrigin 是结构标识的关键一环：
- 设为
'https://a.example.com'：消息只发给该源，浏览器自动丢弃发往其他源的尝试 - 设为
'*'：任何源都能接收，中间人可伪造 iframe 注入恶意监听者 - 若目标页动态加载（如从 CDN 加载 JS），需确保
targetOrigin与实际加载地址一致，否则静默失败 - 服务端渲染页面若含重定向，
targetOrigin应以最终响应头Location为准，而非初始 URL
容易被忽略的边界点：iframe 加载状态与消息时序
即使拿到了 contentWindow，也不能立刻发消息：
-
iframe的src是空字符串或about:blank时，contentWindow存在但尚未加载完成，postMessage报TypeError - 推荐做法：监听
iframeEl.addEventListener('load', () => { popupWin.postMessage(...) }) - 若子页面自身也依赖
postMessage初始化（如微前端子应用），需约定握手协议，例如主窗口先发{ type: 'PING' }，子页回{ type: 'PONG', id: 'main-123' } - 没有 DOM ready 保证：
load仅表示资源加载完，不保证子页 JS 执行完毕，复杂逻辑建议子页主动postMessage({ type: 'READY' })
结构标识不是写个 name 就完事——它是一组可验证、有时序、带权限边界的引用链。一旦跳过 contentWindow 获取时机、绕过 targetOrigin 校验、或忽略加载状态，通信就退化为不可靠的竞态行为。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
