必须用window.postMessage()，因同源策略禁止直接访问跨域iframe的contentWindow等属性，否则抛SecurityError；postMessage是唯一被所有现代浏览器支持、安全可控的原生方案，发送需指定targetOrigin，接收须校验event.origin和event.source。
JavaScript BOM 中处理跨域窗口通信，核心就一条：必须用 window.postMessage()，其他方式要么已淘汰、要么不安全、要么不通用。
为什么不能直接操作跨域 iframe 或窗口
同源策略禁止跨域访问 iframe.contentWindow、window.opener 或 window.parent 的 DOM 和属性。强行读取会抛出 SecurityError: Blocked a frame from accessing a cross-origin frame。这不是兼容性问题，而是浏览器强制执行的安全底线。
postMessage 是唯一可靠方案
它由浏览器原生支持，所有现代浏览器（包括 IE8+）都可用，且机制清晰、可控性强：
- 发送方调用
targetWindow.postMessage(data, targetOrigin)，其中targetOrigin必须写明具体协议+域名+端口（如"https://api.example.com"），禁用"*"（除非你完全信任所有可能的接收方） - 接收方监听
window.addEventListener('message', handler)，并严格校验两个字段：
–event.origin是否匹配预期来源
–event.source是否等于你持有的目标窗口引用（比如iframe.contentWindow） - 消息体只支持可序列化数据（字符串、数字、对象、数组等），不能传函数、DOM 节点、
undefined或Date等非结构化值
实际使用中的关键细节
很多通信失败不是因为 API 不会用，而是忽略了运行时条件：
立即学习“Java免费学习笔记（深入）”；
-
等待加载完成：iframe 尚未加载时，
contentWindow可能为null。务必监听iframe.addEventListener('load', ...)后再发首条消息 - 双向通信需双方配合：父页发消息，子 iframe 必须主动监听；子页回传，父页也得有对应监听逻辑。漏掉任意一端，消息就“石沉大海”
-
中转页可解第三方嵌入难题：当你无法控制 iframe 源站（如广告、支付 SDK），可在自己域名下部署一个
/proxy.html，它与父页同源、与目标 iframe 跨域，再通过两段postMessage桥接，形成“父页 ↔ 中转页 ↔ iframe”链路
已被淘汰或慎用的替代方式
这些方法在当前项目中应避免：
-
document.domain：仅适用于同主域不同子域（如a.example.com↔b.example.com），需双方显式设为相同一级域名。现代架构基本不再依赖此模式，且 Chrome 等已逐步限制其有效性 -
location.hash和window.name：前者有长度限制、易被覆盖、无事件通知；后者虽支持大容量但缺乏校验机制，存在 XSS 风险。两者都不具备可靠性保障，2025 年后主流框架和规范已明确弃用
