JavaScript跨域iframe通信必须通过postMessage等合法协作机制实现，严禁尝试突破同源策略；双方需校验origin、使用可序列化数据，并确保iframe主动暴露响应能力。
JavaScript中无法直接访问跨域iframe的DOM或执行脚本，这是浏览器同源策略的核心防护机制。绕过限制不能靠“突破”，而要依靠双方协作、合法通信机制。关键在于：不尝试读取对方文档内容，改用安全的消息传递。
使用 postMessage 实现双向跨域通信
postMessage 是唯一被广泛支持、标准且安全的跨域iframe通信方式。它要求主页面与iframe双方都主动参与——发送方调用 iframe.contentWindow.postMessage()，接收方在目标窗口监听 message 事件。
- 发送时必须指定目标源（origin），例如
'https://example.com'或'*'（不推荐生产环境） - 接收方务必校验 event.origin，防止伪造消息；同时检查 event.source 是否为预期iframe窗口
- 消息体只能是可序列化的数据（字符串、普通对象、数字等），不能传函数或 DOM 节点
确保 iframe 页面主动暴露通信能力
仅主页面调用 postMessage 不够——iframe 内部需有配套逻辑响应。常见做法是在 iframe 页面加载完成后，向父窗口发送就绪信号，并监听来自父窗口的指令。
- iframe 中可写：
window.parent.postMessage({ type: 'READY' }, 'https://parent-domain.com') - 父页面收到后，再发送具体操作请求，如获取状态、触发行为等
- iframe 接收后解析 type 字段，执行对应逻辑并可再次 postMessage 返回结果
利用 document.domain（仅限同主域不同子域）
当主站与 iframe 来自同一顶级域名（如 a.example.com 和 b.example.com），且服务器可控，可临时降低域限制。
立即学习“Java免费学习笔记（深入）”；
- 双方页面均设置
document.domain = 'example.com'，之后即可直接访问对方 window 对象 - 必须在页面加载早期设置，且只能设为当前域的上级域，不能设为其他无关域名
- 现代开发中已较少使用，因存在安全隐患且不适用于完全不同的域名
服务端代理或 CORS 配合前端跳转（间接方案）
若 iframe 内容本身由你控制，但部署在不同域名，可考虑调整部署结构：
- 将 iframe 指向同源路径，由后端反向代理目标资源（如 Nginx 代理
/proxy/external→https://third-party.com） - 若需加载外部页面且必须交互，可引导用户跳转至目标域，在其页面内完成操作后，用
window.opener.postMessage回传结果 - 注意：不能让 iframe 自己发起跨域请求绕过限制——XMLHttpRequest 或 fetch 同样受同源策略约束
核心原则始终是：跨域不是障碍，而是设计信号。合理划分职责、明确通信契约，比寻找“绕过方法”更可靠也更可持续。
