iframe跨域通信唯一合法路径是postMessage。必须监听onload确保contentWindow可用，严格校验event.origin并指定targetOrigin，禁止使用'*'，双方需双向闭环校验以保障安全。
iframe 跨域通信只有一条路能走通：postMessage。其他任何试图直接读写 contentWindow 或 contentDocument 的操作，都会被浏览器当场拦截，报错 SecurityError: Blocked a frame with origin "https://a.com" from accessing a cross-origin frame。
父页面怎么安全地向跨域 iframe 发消息
不能等页面一加载完就发，也不能把 targetOrigin 写成 '*' —— 这两个动作是出错最密集的地方。
- 必须监听
iframe.onload事件，确保 iframe 已完成加载，contentWindow不为null - 发送前要显式判断
iframe.contentWindow是否存在，避免Cannot read property 'postMessage' of null -
targetOrigin必须写明具体协议+域名+端口（如'https://embed.example.com'），不能用'*'，除非你 100% 控制 iframe 所有可加载地址 - 传的数据只能是可结构化克隆的对象：普通对象、数组、字符串、数字、Date、RegExp；不能含函数、
undefined、DOM 节点，否则静默失败
子 iframe 怎么收消息并防冒充
接收方不校验 event.origin，等于把接口暴露给任意网站。哪怕只比对 event.data.type，也毫无意义。
- 必须用严格相等（
===）比对event.origin，例如if (event.origin !== 'https://parent.example.com') return - 不能用
includes()、正则或模糊匹配，这些都可能被绕过 - 如果父页可能从多个环境加载（如
https://dev.example.com和https://prod.example.com），需维护白名单数组，用['https://dev.example.com', 'https://prod.example.com'].includes(event.origin) - 响应时也要指定目标源：
event.source.postMessage(response, event.origin)，别用'*'
为什么 iframe.contentWindow 总是 null 或报 SecurityError
这不是代码写错了，是浏览器在严格执行同源策略 —— 它不允许你碰，你就真不能碰。任何绕过尝试（比如改 document.domain）在现代浏览器中基本失效或已被废弃。
立即学习“前端免费学习笔记（深入）”；
- 跨域 iframe 的
contentWindow和contentDocument属性在 JS 中是“存在但不可访问”的状态：你能读到它，但调用任何方法或读取任何属性都会触发SecurityError -
document.domain只适用于同主域不同子域（如a.example.com↔b.example.com），且要求双方显式设置相同值，现已不推荐用于新项目 - 没有“配置一下就能访问”的后门。唯一合法路径就是双方约定好消息格式，走
postMessage协作
真正容易被忽略的不是语法，而是时序和信任链：子 iframe 必须在 window 上提前注册 message 监听器（最好放在 <script> 最顶部），父页必须等 load 后再发；双方的 origin 校验必须双向闭环，漏掉任意一端，安全模型就崩了。
