javascript中iframe跨域通信必须用window.postmessage()，因同源策略禁止直接访问contentwindow、parent等属性而抛securityerror；发送需指定targetorigin，接收须严格校验event.origin。
JavaScript 中 iframe 和 parent 无法直接跨域通信，这是浏览器同源策略强制限制的。但可以通过 postMessage API 安全、标准地实现跨域数据交互，它不绕过安全机制，而是被浏览器明确支持的跨域通信方案。
为什么不能直接访问 parent 或 iframe 的 DOM/变量？
当 iframe 的 src 与父页面协议、域名、端口任一不同，就构成跨域。此时：
- iframe.contentWindow 可获取引用，但访问其 document、window.xxx 会抛出 SecurityError
- 父页也无法读取 iframe.contentWindow.location（会返回空或报错）
- parent、top、self 在跨域子帧中同样受限
用 postMessage 实现双向跨域通信
核心是双方都调用 window.postMessage() 发送消息，并监听 message 事件接收。关键点在于：验证来源、指定目标窗口、结构化传参。
-
发送方（如子 iframe 向父页发数据）：
parent.postMessage({ type: 'LOGIN_SUCCESS', user: { id: 123 } }, 'https://parent.com')
第二个参数必须是目标窗口确切的 origin（不能用*，除非完全信任所有来源） -
接收方（父页监听子 iframe 消息）：
window.addEventListener('message', (e) => { if (e.origin !== 'https://child.com') return; // ✅ 必须校验 origin if (e.data.type === 'LOGIN_SUCCESS') { console.log('收到用户信息：', e.data.user); } }); -
父页向子 iframe 发消息（需先获取 iframe 引用）：
const iframe = document.getElementById('myIframe');<br> iframe.contentWindow.postMessage({ cmd: 'SET_THEME', theme: 'dark' }, 'https://child.com');
常见陷阱和加固建议
postMessage 易用但不安全——若不严格校验，可能被恶意 iframe 伪造消息或父页误收其他来源消息。
-
永远校验
e.origin，不要只看e.source——source是窗口引用，origin 才是真实来源地址 -
避免使用
'*'作为 targetOrigin，尤其传输敏感数据时；生产环境必须写死可信域名 -
子 iframe 主动获取父页消息时，需等
load事件后执行 postMessage，否则父页可能尚未监听 - 可配合自定义事件封装通信层，例如统一处理序列化、超时、应答确认（类似 RPC），提升健壮性
替代方案对比（不推荐但需了解）
除 postMessage 外，有些老方案已被淘汰或存在严重缺陷：
- document.domain：仅适用于同主域不同子域（如 a.example.com ↔ b.example.com），且需两端显式设置相同 domain，现代浏览器限制更严，已不推荐
- window.name：利用 iframe 的 name 属性跨域传字符串，无安全性、无类型、易冲突，纯 hack，勿用于新项目
- 服务端代理 / CORS：适合 API 请求，不解决 iframe 页面间实时交互问题
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
