postmessage是唯一被现代浏览器广泛支持、安全且通用的跨域iframe通信方式，需父页等待iframe加载完成并指定精确targetorigin发送消息，子页严格校验event.origin后处理结构化数据，双方共同参与双向通信。
直接访问跨域 iframe 的 contentWindow 或 contentDocument 会触发浏览器同源策略拦截，报 SecurityError 或返回 null —— 这不是代码写错了，而是浏览器强制执行的安全机制，无法绕过，只能适配。
必须用 postMessage 实现双向通信
这是唯一被现代浏览器广泛支持、安全且通用的跨域 iframe 通信方式。父页面和子页面都需主动参与，不能只靠一方操作。
- 父页发消息前，必须等
iframe.onload触发，确保子页面完全加载完毕；再检查iframe.contentWindow是否存在，避免Cannot read property 'postMessage' of null - 发送时
targetOrigin必须写死域名，例如'https://child.example.com'，禁用'*'，否则任意网站都能监听或伪造指令 - 子页监听
message事件时，必须严格比对event.origin，仅处理来自可信源的消息；所有 DOM 更新、函数调用都由子页内部完成，父页不越权操作
避免踩坑的关键时机与判断
很多错误其实源于时机错乱或校验缺失，而非通信逻辑本身。
- 不要在
DOMContentLoaded后立刻发消息——此时 iframe 可能还没开始加载资源，contentWindow仍为null - 如果 iframe 的
src动态切换（如测试环境切生产），需在每次发送前读取当前iframe.src，匹配对应targetOrigin，不能硬编码一个地址 - 子页收到消息后，不要只看
event.data.type就执行操作，忽略origin校验等于开放远程控制权限
其他方案已基本淘汰或适用极窄
像 document.domain 只适用于同主域不同子域（如 a.example.com 和 b.example.com），且要求双方显式设置相同值；window.name 方案依赖页面跳转中 name 值保留的特性，需额外代理页中转，维护成本高、可读性差，也不支持实时通信。
- HTML5 已废弃
frameborder、scrolling等属性，新项目应使用sandbox和allow控制 iframe 权限 -
srcdoc可嵌入内联 HTML，规避跨域问题，但仅适合静态、小体量内容，无法加载外部脚本或完整站点 - CORS 是针对 HTTP 请求的机制，对 iframe 的 DOM 访问无效，不能解决
contentWindow被锁问题
安全底线：沙箱与权限最小化
即便通信走 postMessage，iframe 本身也应尽可能受限。
- 启用
sandbox属性（如sandbox="allow-scripts allow-same-origin"），默认禁用脚本、表单提交、弹窗等能力，按需放开 - 用
allow显式声明所需权限，例如allow="geolocation; camera"，避免宽泛授权 - 敏感操作（如支付、登录）不应放在跨域 iframe 中，防止点击劫持（Clickjacking）等攻击
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
