直接操作跨域 iframe 的 DOM 被浏览器同源策略强制禁止，无法绕过；唯一安全通用方案是 postMessage API，由子页面自身执行 DOM 操作，父页面仅发送指令并校验 origin。
直接操作跨域 iframe 的 dom 是被浏览器强制禁止的，这是同源策略的核心保护机制，无法绕过。真正可行的路径不是“突破限制”，而是改用安全、标准的跨域通信方式，把 dom 操作逻辑交由 iframe 自身完成。
同源时可直接操作 DOM
当父页面与 iframe 页面满足协议、域名、端口三者完全一致时，可自由访问其内部元素：
- 用 iframe.contentDocument 或 iframe.contentWindow.document 获取子页面 document 对象
- 调用 getElementById、querySelector 等方法操作子页面 DOM
- 执行 iframe.contentWindow.xxxFunction() 调用子页面暴露的方法
若尝试访问时抛出 SecurityError，说明已跨域，此时必须切换方案。
跨域时唯一推荐：postMessage API
这是现代浏览器唯一原生支持、安全、通用且无需服务端配合的跨域通信方案。关键在于“消息驱动”而非“DOM直取”：
- 父页发送：调用 iframe.contentWindow.postMessage(data, targetOrigin)，targetOrigin 必须精确指定（如 https://b.com），不可用 *
- 子页接收：监听 window.addEventListener('message', handler)，并在 handler 中严格校验 event.origin === 'https://b.com'
- 子页操作 DOM：收到消息后，在子页面内部执行真实 DOM 修改（比如隐藏按钮、填充表单），不向父页暴露 document 引用
例如：父页想让 iframe 里的搜索框自动聚焦，就发一条 {type: 'focusSearch'} 消息；iframe 收到后自己调用 input.focus()。
其他方案为什么不建议
除 postMessage 外的多数方法都存在明显缺陷：
- document.domain：仅适用于主域相同但子域不同的场景（如 a.example.com ↔ b.example.com），且需双方主动设置，现代项目中使用率极低
- location.hash / window.name：数据量小、易被截获、触发 URL 变化、不支持二进制或复杂对象，已属历史方案
- 代理页面 / CORS / JSONP：适用于接口请求，不解决 iframe 与父页之间的双向 JS 通信问题
- 服务器端渲染或重定向传参：属于初始化阶段的数据传递，无法支撑运行时动态交互
这些方法或适用面窄，或有安全隐患，或维护成本高，新项目应直接放弃。
调试与验证要点
实际落地时容易忽略几个关键细节：
- 确保 iframe 已加载完成再调用 postMessage，可用 iframe.onload 或 DOMContentLoaded 判断
- 检查 event.source 是否为预期 iframe 的 window，避免被恶意 iframe 伪造消息
- 子页面处理完消息后，如需反馈，应由子页再调用 parent.postMessage() 回传，形成闭环
- 在开发环境注意 HTTPS 与 HTTP 不同源——哪怕域名一样，协议不同也属跨域
