关于iframe跨域，先给结论
iframe跨域通信的核心解法是postMessage，配合正确的目标源校验，没有比这更通用的方案。不管理论上说得多么复杂，落到代码上就是一条message事件监听加一条postMessage调用，大多数前端团队在生产环境中遇到的跨域问题，靠这个API就能解决八成以上，如果碰到极端场景，比如满足某些浏览器兼容条件时，还能用location.hash和window.name做兜底，但这两条路只适合特定场景,优先级远低于postMessage。
在写业务代码前，先确认一个容易被忽略的事实：iframe跨域问题分为两类，一类是跨域报错导致脚本无法操作对方，另一类是数据传递不通，前者用postMessage绕开同源策略的限制，后者考验的是对事件机制的理解，很多人把这两件事混在一起排查,浪费大量时间。
iframe跨域报错的常见场景和定位方法
遇到跨域问题容易蒙圈，先判断报错属于哪种类型，常见的跨域报错有几种表现,每种对应的处理手段不一样。
无法读取或操作跨域iframe的DOM
这是最常见的一种，父页面里嵌入了一个其他域名的iframe，你想直接用iframe.contentDocument去改里面的内容，控制台马上会报Blocked a frame from accessing a cross-origin frame，这是浏览器的同源策略在拦截,从根上就禁止这种直接操作。
这种情况下，可以考虑用邮件或系统通知来替代这种需求，如果一个简单的跨域页面嵌套已经让你在处理DOM操作，建议先在架构上讨论页面拆分是否合理，可以考虑将需要交互的部分拆到同一个域下，或者走服务端转发，浏览器不会放过你，就算你用了一些老旧的hack手法,现代浏览器也早就封死了。
postMessage通信不生效，消息发不过去
postMessage发消息的语法很简单，targetWindow.postMessage(data, targetOrigin)，targetOrigin必须明确指定，不能直接写，否则部分浏览器和严格的安全策略会直接无视，很多开发者的第一反应是“为什么收不到”，然后去查两边的监听,根本没意识到问题出在targetOrigin这个参数上。
还有一种情况，接收方的message事件监听没有提前绑定，导致发送方先发了消息，接收方后绑定事件，消息丢了，这不算跨域问题，是时序问题，但会以跨域通道“不工作”的表现形式暴露出来。
第三方cookie被禁导致会话丢失
部分场景下，iframe嵌套页面需要带上用户的登录态，如果嵌入了不同域的页面，第三方cookie默认被浏览器拦截，登录态就丢了，这个问题的坑在于，本地开发时正常，部署上线后偶尔正常偶尔异常，这种问题用postMessage解决不了,那是另一种问题范畴。
解决思路是改用token放在postMessage里传递，由父页面统一维护登录状态；或者JS-SDK方式让子页面自己处理认证，没别的好办法，浏览器的策略越来越严,属于趋势性问题。
iframe跨域通信的正确方式：postMessage使用详解
从实际使用角度来看，postMessage是唯一需要熟练掌握的方案，它能把数据从一个窗口安全地传递到另一个窗口，包括跨域的iframe以及window.open打开的窗口。
发送端：确认目标窗口引用和targetOrigin
有几种情况需要区分，比如父页面给iframe发消息，你需要拿到iframe的contentWindow；反过来，iframe给父页面发消息，你需要拿到parent或top，具体写法是一行代码的事情,但很多人犯的错误是拿错了窗口引用。
// 父页面发送消息给iframe
const iframe = document.getElementById('childFrame');
iframe.contentWindow.postMessage({ type: 'UPDATE_USER', data: { id: '123' } }, 'https://child.example.com');
// iframe内部发送消息给父页面
window.parent.postMessage({ type: 'IFRAME_READY' }, 'https://parent.example.com');
targetOrigin到底写什么，如果你确定对方页面的确切域名，就写完整的协议加域名加端口，如果不确定，先写调试，调试通过后务必改成具体值，行业共识认为，生产环境把targetOrigin设为是不安全的行为,任何第三方站点都能收到这份消息。
接收端：用message事件监听并校验来源
接收消息要用window.addEventListener('message', handler)，handler里有个event.origin属性，这是发送方的源，校验这一步必须做，不做的后果是任何人都能给你的页面发送消息,诱导你的页面执行一些操作。
window.addEventListener('message', (event) => {
// 校验来源，防止恶意消息
if (event.origin !== 'https://parent.example.com') return;
// 校验数据结构
if (!event.data || typeof event.data !== 'object') return;
const { type, data } = event.data;
switch (type) {
case 'UPDATE_USER':
renderUserInfo(data);
break;
case 'IFRAME_READY':
console.log('子页面已就绪');
break;
default:
break;
}
});
校验event.origin这步是行业共识中强调的安全底线，不做好这步，整个iframe跨域通信方案就不完整，即使targetOrigin写了具体域名，接收端依然必须校验,这是双向保障。
在接收message事件时，还要注意一个细节：事件里的data可能是任意类型，浏览器会做结构化克隆算法，也就是说，你可以传递对象、数组，甚至部分类型的二进制数据，不用自己序列化，但不能传函数、DOM节点、Symbol这类特殊值,传了会报错。
子iframe和父页面之间的消息时序处理
既然用到了postMessage，先理清一个经典的“先后”问题，大多数业务场景是这样的：父页面加载iframe，iframe里发起一个请求，请求完成后把结果通知父页面，你需要在iframe加载完后，用postMessage通知父页面“我准备好了”,然后父页面再发下一步指令。
一个稳定的模式是：iframe内部初始化完成后主动上报一条IFRAME_READY消息；父页面收到之后再发送具体的业务消息，同时父页面也可以设置一个超时定时器，比如3秒内没收到ready消息就显示加载异常，这个思路比在父页面等iframe的onload事件再发消息要靠谱得多，因为onload事件只能说明页面加载完,不代表内部数据都初始化好了。
iframe跨域通信的备用方案：location.hash和window.name
提到iframe跨域通信方案，多数人会先想到location.hash方案，它的原理是父页面可以修改iframe的src的hash部分，iframe内部通过监听hash变化获取数据，反过来，iframe修改自己的src的hash，父页面监听iframe的src变化来获取数据，这一来一回的数据量不大，只能传字符串，长度还不能太长，否则URL可能会被截断，这个方案在如今的前端工程化项目里基本被postMessage取代了，但如果你在维护老项目,可能还会见到。
window.name方案是利用了一个特性：一个窗口的name属性在窗口被替换后依然保留，比如父页面先让iframe加载一个同域页面，那个页面把数据塞进window.name，然后iframe再被导航到跨域页面，跨域页面里依然能读到之前设置的window.name，这绕了一圈，在以前是个经典技巧，现在用得少了，这个方案代码写着绕，不太符合常人的思维方式,而且安全性不好控制。
真正的选择标准：首先考虑postMessage，遇到兼容性问题且数据量小（比如传一个状态值），才考虑location.hash，多数情况下，postMessage已经覆盖了主流的应用场景,再做其他方案的意义不大。
iframe跨域在不同业务场景下的处理细节
iframe跨域postMessage在支付回调场景中的应用
常见一个场景，主站页面里嵌入了第三方支付机构的收银台iframe，支付完成后的回调通知，主站怎么知道呢？一般有两种解法：第一种，调用支付接口时直接拿到支付结果，主站轮询后端订单状态接口，这个跟iframe没关系，第二种,支付页通过postMessage把支付结果传给主站。
实际开发中，我倾向于优先采用轮询后端的方式，因为它天然不受跨域限制，同源策略管不到XHR和fetch，用postMessage做支付结果通知可以减轻后端压力，但如果网络不稳定，消息可能丢失，所以最好两者结合，至少单靠postMessage通知并不可靠,生产环境出问题很难排查。
判断iframe是否跨域以及同域情况下的简化处理
这个判断很重要，会直接影响代码方案，如果主页面和iframe是同一个域（协议、域名、端口完全一致），你完全可以用contentDocument、contentWindow直接操作对方DOM,不需要postMessage。
但要注意，有时候页面在本地打开是file://协议，目录不同也可能导致跨域，比如两个file页面虽然都在本地，依然可能被浏览器判定为跨源,这类问题通常在本地调试时能第一时间暴露出来。
写代码之前，先判断一下你的业务场景里页面和iframe是不是同域，同域就用最直接的方式；跨域就用postMessage,这是一条很清晰的标准。
iframe跨域对contentDocument和contentWindow操作的限制
前面提到contentDocument和contentWindow，再说明白一点，跨域时这些属性无法访问，访问会抛SecurityError，但有一种折中情况：你可以访问contentWindow的某些属性，比如postMessage方法，但不能访问contentWindow.document，也不能访问contentWindow.location。
实际开发中，可能用contentWindow.location去重定向iframe，这在同域下没问题，跨域下会被拦，如果你确实需要让跨域iframe跳转，要么让iframe内部自己跳，要么用postMessage通知它去跳，父页面不能直接用JS改变跨域iframe的src，如果你只是给iframe标签设置src属性（比如iframe.src = '...'），那是允许的，但这是属性操作，不是跨域窗口导航,两者是有区别的。
iframe跨域安全边界：消息校验和风险规避
做全来源校验和数据结构校验
前面说过必须校验event.origin，另外强烈建议对所有消息的数据结构做一次校验，如果收到的数据不是预期结构，直接return，实际项目中有一种安全风险，攻击者向页面发送一条消息，里面带的data是一个恶意的链接，页面拿到后直接用innerHTML插进去了，这种情况做再完备的origin校验也没用,数据校验才是最后一道防线。
建议用一个统一的消息类型约束业务数据
设计一个{ type: string, data: any }的通用结构，发送端和接收端都按这个结构来处理，看起来简单，但实践中能避免很多因为数据格式不统一导致的隐蔽bug，消息丢失的时候，加一个requestId用于追踪和做超时重试。
注意iframe的sandbox属性对postMessage的影响
HTML5的sandbox属性可以限制iframe的能力，如果iframe设置了sandbox属性且没有allow-scripts，那么里面所有的脚本都被禁止执行，包括postMessage监听逻辑，如果你在调试一个上述跨域通信模块时发现父页面收不到iframe的消息，检查一下iframe标签有没有加sandbox，这是一个常见的坑,且报错往往不直观。
sandbox的另外一个隐藏细节是，它还会让iframe被视为一个独立的源，即使iframe的URL和父页面同域，只要加了sandbox，也会变成跨域，postMessage仍然可以传递消息,但DOM操作就没戏了。
性能优化和用户体验方面的相关思考
UI渲染和数据加载是两个纬度，iframe本来就是一个独立文档，它有自己独立的渲染流程，有独立的JavaScript执行环境，嵌入iframe必然会增加页面总体的资源加载量，优化手段之一是给iframe设置loading="lazy"属性，如果是页面靠下的iframe，可以让它延迟加载,这属于懒加载的标准做法。
通信频率也是个需要考虑的点，postMessage虽然轻量，但频率很高也会带来性能压力，如果父页面需要接收子页面的某个状态数据，而子页面状态变化很频繁，建议在子页面做一下节流，比如requestAnimationFrame或者setTimeout，因为postMessage每触发一次，接收方的JavaScript线程就要消耗一次处理时间,高频消息会导致页面卡顿。
关于iframe跨域常见问题的Q&A
问题1：iframe跨域通信方案中，postMessage怎么把事件绑定在正确对象上？
答：接收方在哪个窗口监听，就写在哪个窗口里，如果是iframe内部需要接收父页面消息，就在iframe的window上绑定message事件，如果是父页面需要接收iframe的消息，就在父页面的window上绑定，还要注意事件绑定需要timeout，如果绑定时机太晚，之前发送的消息就收不到了，具体做法是让iframe加载完成后主动发送一条READY消息,父页面收到后再开始正式通信。
问题2：iframe跨域通信安全吗？有哪些防护措施？
答：postMessage本身是安全的，不安全的是使用姿势，防护手段主要有以下几种：发送时明确指定targetOrigin而不是写通配符，接收时用Origin头校验消息的发送来源，定义统一的数据结构并做字段类型校验，对涉及页面跳转或其他敏感操作的消息单独增加token校验，任何窗口都可以向你的页面发送消息，你无法阻止这种发送行为，只能通过校验把外部消息全部拦截掉，这种机制下,校验到位就是安全的。
问题3：postMessage传参可以传Function吗？会不会报跨域错误？
答：不能，postMessage的data参数遵循结构化克隆算法，Function、DOM节点、Symbol等无法被结构化克隆的数据类型，传递时会被直接抛错（DataCloneError），常见的做法是传对象，比如{ type: 'CALLBACK', id: 'cb_001' }，接收方根据type和id来判断要执行哪个具体的函数，RegExp、Date、Map、Set这类复杂数据类型是可以传的，因为结构化克隆算法支持它们，关于数据的序列化深度，只要数据能被结构化克隆，理论上都可以传，但要注意数据量过大会造成性能开销，比如传一个几十MB的数组,消息发送和接收都会有一定的耗时。
选对方案，绕开iframe跨域的天坑
回到那句话，iframe跨域不是洪水猛兽，postMessage就是那把钥匙，校验来源、定义结构、小心时序，这几个点做好，跨域通信就能稳定运行，开发过程中优先用postMessage，其次考虑同域情况下的DOM直操作，最后才考虑hash和name这类传统方案，前端开发里，因跨域而推翻整个架构的做法通常没必要架构定义边界，通信解决边界两侧的对话问题，这个行业里大部分业务场景根本走不到“推翻重来”那一步。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/578698.html
