postMessage是当前唯一无需服务端配合、能安全完成iframe跨域通信的标准方案；其核心在于双向origin校验、精确targetOrigin指定及异步消息设计，缺一不可。
直接说结论：用 postMessage 是当前唯一无需服务端配合、能安全完成 iframe 跨域通信的标准方案。但“能发”不等于“安全”，漏掉 origin 校验或乱用 "*" 就等于把数据裸奔发出去。
为什么不能直接访问 contentWindow？
因为浏览器的同源策略会拦截跨域 iframe 的 contentWindow 属性读取，连 iframe.contentWindow.document 都会报 SecurityError。这不是权限没开，是浏览器硬性禁止——哪怕你只是想调个函数、读个变量，都不行。
常见错误现象包括：
Blocked a frame with origin "https://a.com" from accessing a cross-origin frame.- 在控制台看到
Cannot read property 'xxx' of null，其实是contentWindow返回null或被拦截
这时候别折腾 document.domain（只适用于子域场景）或 JSONP（不适用于 iframe 通信），直接切到 postMessage 路线。
怎么写一个不被绕过的 origin 校验？
接收方必须验证 event.origin，否则任何页面都能伪造消息冒充合法来源。只校验协议+域名+端口，不拼接路径，也不用正则模糊匹配。
- ✅ 正确写法：
if (event.origin !== 'https://b.com') return; - ❌ 错误写法：
if (!event.origin.includes('b.com')) return;（会被https://evil-b.com绕过） - ❌ 危险写法：
if (event.origin === '*')（event.origin永远不会是"*"，这行永远为 false）
如果目标源有多个（比如测试环境用 http://localhost:3000，线上用 https://prod.com），就用白名单数组比对：
const ALLOWED_ORIGINS = ['https://prod.com', 'http://localhost:3000']; if (!ALLOWED_ORIGINS.includes(event.origin)) return;
父页发消息给子 iframe 的关键步骤
发送前要确保 iframe 已加载完成，否则 contentWindow 可能为 null；同时避免把敏感数据明文塞进 message 参数里。
- 监听
iframe.onload或用iframe.addEventListener('load', ...)，而不是靠setTimeout猜时机 - 发送时指定精确的
targetOrigin，比如iframe.contentWindow.postMessage(data, 'https://b.com') - 不要传
localStorage、cookie或用户凭证等敏感字段；如需传递 token，应走后端签发的短期有效票据，并由子页自行向自己后端校验 - IE9–10 不支持对象序列化，若需兼容，先
JSON.stringify()再发，子页再JSON.parse()
子页回传数据给父页时要注意什么？
子页调用 parent.postMessage() 时，targetOrigin 应该填父页的实际源，不是 "*"，也不是空字符串。父页收到后，也要校验 event.origin 是否可信。
- 子页发送：
parent.postMessage({type: 'READY', payload: {...}}, 'https://a.com') - 父页接收时，
event.source是子页的window引用，可用于后续单向通信（比如父页再发指令），但不能绕过 origin 校验直接调用其方法 - 如果子页需要响应多次请求，建议在消息体中加
id字段做请求标识，避免响应错乱
最容易被忽略的一点：postMessage 是纯异步、无确认机制的。发了不等于对方收到了，更不等于处理成功。业务关键链路（比如支付跳转后等待结果）必须设计超时重试 + 回调兜底，不能只靠一次 postMessage 就认为通信已完成。
