1. 从一次诡异的表单提交失败说起前阵子帮一个做后台管理系统的朋友排查问题现象特别邪门页面里嵌了一个 iframe里面加载的是另一个独立部署的表单页。用户在 iframe 里填完信息点提交主页面这边完全没反应控制台干干净净网络请求也没发出去。朋友一口咬定是后端接口挂了我让他把 iframe 单独在新标签页打开提交一切正常。问题就出在父子这两个字上。iframe 里的页面和外面的主页面在浏览器眼里是两个独立的文档环境各自有各自的window、document默认情况下它们之间是老死不相往来的。你在 iframe 里点按钮事件只在 iframe 内部冒泡外面那层根本感知不到。这不是 bug这是浏览器的安全设计。iframe实现父子内容通信说白了就是解决两个独立页面怎么互相喊话的问题。它看起来简单但真正落地时会牵扯到同源策略、跨域限制、消息格式约定、生命周期时序、内存泄漏等一堆细节。我见过太多项目在这上面翻车有的用window.parent直接调方法本地开发好好的一上线跨域就报Blocked a frame with origin...有的用postMessage但忘了校验来源埋下安全隐患还有的在 iframe 还没加载完就去通信拿到一堆undefined。这篇内容我打算把 iframe 父子通信这件事从头到尾捋一遍。不管你是刚接触 iframe 的新手还是被跨域通信折磨过的老手都能从里面找到能直接抄作业的方案。我会讲清楚同源和跨域两种场景分别怎么处理、postMessage的正确姿势、时序问题怎么规避、以及几个我踩过的真实坑。核心关键词就三个iframe 父子通信、postMessage、同源策略围绕它们展开。2. 先搞懂浏览器给 iframe 划的那条楚河汉界在动手写代码之前必须先把底层规则搞清楚否则你写的每一行通信代码都是碰运气。iframe 父子通信的所有坑根源都在浏览器的同源策略上。2.1 同源到底同的是什么同源策略里的源由三部分组成协议、域名、端口。三者完全一致才算同源。举个例子https://a.example.com和下面这些地址的关系是这样的对比地址是否同源原因https://a.example.com/page是协议、域名、端口全一致路径不影响http://a.example.com否协议不同https 对 httphttps://b.example.com否域名不同子域名也算不同源https://a.example.com:8080否端口不同默认 443 对 8080这里有个特别容易被忽略的点子域名之间默认也不同源。a.example.com和b.example.com在浏览器看来是两个完全不同的源哪怕它们指向同一台服务器。很多公司把主站和子系统部署在不同子域下结果 iframe 通信直接歇菜就是栽在这上面。同源的时候父子页面可以肆无忌惮地互相访问父页面能拿到iframe.contentWindow能读iframe.contentDocument能直接调 iframe 里定义的方法iframe 里也能通过window.parent反向操作父页面。这种模式下通信最省事但也是最容易写出耦合代码的地方。2.2 跨域时浏览器到底拦了什么跨域的时候浏览器不是把所有操作都拦死而是分层次的。理解这个层次你才知道哪些路能走、哪些路走不通。第一层DOM 访问被拦。父页面想读iframe.contentDocument跨域情况下直接抛异常报Blocked a frame with origin ... from accessing a cross-origin frame。你想拿到 iframe 里的某个元素、改个样式门都没有。第二层JS 对象访问被拦。父页面想调iframe.contentWindow.someMethod()同样被拦。反过来 iframe 想调window.parent.someMethod()也一样。但是有个例外window.parent、window.top、window.length这几个属性是允许访问的还有postMessage方法也是允许调用的。这几个漏网之鱼就是跨域通信的突破口。第三层网络请求不受同源策略直接限制。iframe 里发起的请求是 iframe 自己那个源的请求跟父页面没关系。父页面拦不住也管不着除非用 CSP 之类的策略。注意很多人以为跨域就是完全不能通信其实不是。浏览器留了postMessage这个官方通道专门用来做跨域通信。关键是要用对。2.3 为什么浏览器要这么设计理解设计动机你才能理解为什么有些歪招不能用。同源策略的核心目的是防止恶意页面窃取数据。设想一下如果没有同源策略你打开一个恶意网站它偷偷在页面里嵌一个 iframe 加载你的网银页面然后通过iframe.contentDocument读取你的账户信息、甚至模拟点击转账那就彻底乱套了。所以浏览器必须把不同源的文档环境隔离开。但隔离归隔离现实业务里确实有合法的跨域通信需求比如主站嵌一个第三方支付页面、嵌一个地图组件、嵌一个客服系统。于是postMessage应运而生它提供了一条受控的、需要双方显式配合的通信通道。你发消息要指定目标源收消息要校验来源源双方都同意才能通信。搞清楚了这层设计逻辑后面所有的代码写法就都顺理成章了。3. 同源场景能直接调但别调出一身债同源场景下父子通信是最简单的简单到很多人会滥用。我先把能用的方法列出来再讲讲为什么我不建议你随便用。3.1 父调子的几种写法父页面操作 iframe 里的内容核心是拿到contentWindow和contentDocument。假设页面里有个iframe idchildFrame src/child.html/iframe父页面可以这样写const iframe document.getElementById(childFrame); // 拿到 iframe 的 window 对象 const childWindow iframe.contentWindow; // 拿到 iframe 的 document 对象 const childDocument iframe.contentDocument || iframe.contentWindow.document; // 调用 iframe 里定义的方法 childWindow.doSomething(来自父页面的参数); // 直接操作 iframe 里的 DOM const childButton childDocument.getElementById(submitBtn); childButton.style.backgroundColor red;这里有个兼容性细节老版本 IE 需要用contentWindow.document现代浏览器contentDocument就够了。现在基本可以忽略 IE但如果你维护的是老系统加个||兜底没坏处。3.2 子调父的写法iframe 里反向操作父页面靠的是window.parent和window.top。parent是直接父级top是最顶层窗口。如果只有一层嵌套两者一样如果多层嵌套top会一路找到最外层。// 调用父页面的方法 window.parent.handleChildMessage(子页面发来的数据); // 操作父页面的 DOM window.parent.document.getElementById(status).innerText 子页面已就绪; // 如果嵌套多层想找最顶层 window.top.someGlobalMethod();3.3 直接调用为什么是个甜蜜的陷阱同源直接调用看起来很方便但我强烈建议你即使同源也优先用 postMessage。原因有三个都是血泪教训。第一个原因是耦合。父页面直接调childWindow.doSomething()意味着父页面必须知道子页面暴露了哪些方法、方法名叫什么、参数怎么传。子页面一改方法名父页面就崩。两个页面被死死绑在一起谁都不敢单独改。我见过一个项目父子页面是同源直接调用的后来子页面要独立部署到另一个域名下整个通信逻辑推倒重写改了两天。第二个原因是时序。iframe.contentWindow在 iframe 还没加载完的时候可能是个空壳或者不完整的状态。你直接调方法很可能报xxx is not a function。你得监听iframe.onload才能保证子页面就绪。但onload只保证文档加载完如果子页面里还有异步初始化逻辑onload触发时方法可能还没挂上去。这个时序问题在同源直接调用里特别难处理。第三个原因是迁移成本。今天同源明天可能就跨域了。业务发展过程中把子系统拆到独立域名下是常有的事。如果你一开始就用 postMessage跨域时几乎不用改代码如果用的是直接调用那就得全部重写。我的经验是把父子通信当成两个独立服务之间的接口来设计用消息传递而不是方法调用。这样无论同源还是跨域代码结构都一样迁移零成本。4. postMessage跨域通信的唯一正解postMessage是 HTML5 引入的跨文档通信 API专门解决不同源窗口之间的通信问题。它的设计很克制发送方指定目标窗口和目标源接收方校验来源源双方通过约定好的消息格式交换数据。4.1 发送消息的正确姿势发送消息用targetWindow.postMessage(message, targetOrigin, [transfer])。三个参数里前两个是必填的。// 父页面向 iframe 发消息 const iframe document.getElementById(childFrame); iframe.contentWindow.postMessage( { type: INIT, payload: { userId: 123 } }, https://child.example.com ); // iframe 向父页面发消息 window.parent.postMessage( { type: READY, payload: null }, https://parent.example.com );message参数可以是任意可结构化克隆的对象字符串、数字、对象、数组都行。但注意函数、DOM 节点、Error 对象这些不能传会直接抛异常。实际项目里我建议统一用对象格式带上type字段区分消息类型payload字段装数据这样扩展性好。targetOrigin参数是安全的关键。它指定了只有这个源的窗口才能收到消息。如果你写成*意味着任何源都能收到这在生产环境是绝对禁止的。因为如果父页面被恶意页面通过某种方式嵌了或者 iframe 被替换成了恶意页面你的敏感数据就泄露了。正确做法是写死具体的源比如https://child.example.com。4.2 接收消息与来源校验接收消息靠监听message事件window.addEventListener(message, function(event) { // 第一步校验来源源不通过直接返回 const allowedOrigins [https://child.example.com, https://parent.example.com]; if (!allowedOrigins.includes(event.origin)) { console.warn(收到未知来源的消息已忽略:, event.origin); return; } // 第二步解析消息 const data event.data; if (!data || typeof data ! object) { return; } // 第三步按类型分发处理 switch (data.type) { case INIT: handleInit(data.payload); break; case READY: handleReady(data.payload); break; default: console.warn(未知消息类型:, data.type); } });这里有几个细节必须强调。event.origin是发送方的源一定要校验而且要用白名单精确匹配不能用includes做模糊匹配。比如https://child.example.com和https://child.example.com.evil.com用includes判断前者会误判后者为合法。正确做法是event.origin https://child.example.com这种精确相等。event.source是发送方的窗口引用可以用来回消息。比如父页面收到 iframe 的消息后想回复可以用event.source.postMessage(...)这样不用再去查 iframe 元素。4.3 消息格式的约定比代码本身更重要我见过太多项目postMessage 的代码写得没问题但消息格式一团糟。父页面发{a: 1}子页面期望{data: {a: 1}}对不上就各种undefined。所以在动手写代码之前先把消息协议定下来。我一般会定一个这样的协议表消息 type发送方数据格式说明PARENT_INIT父{ userId, token }父页面初始化时下发用户信息CHILD_READY子{}子页面就绪请求初始化数据CHILD_SUBMIT子{ formData }子页面提交表单数据PARENT_SUBMIT_RESULT父{ success, message }父页面返回提交结果PARENT_RESIZE父{ height }父页面通知子页面调整高度协议定好之后双方各自实现自己的收发逻辑联调时对着协议表排查效率高很多。协议表最好写在文档里别只存在某个人脑子里。5. 时序问题为什么你的消息总是发早了postMessage 本身是异步的但比异步更麻烦的是时序。父页面和 iframe 是两个独立的加载过程谁先加载完、谁先初始化好是不确定的。我踩过最典型的坑就是父页面在DOMContentLoaded里就给 iframe 发消息结果 iframe 还没加载完消息石沉大海。5.1 父子加载顺序的不确定性设想一个场景父页面加载时iframe 的src指向一个子页面。父页面的 JS 执行到发消息那行时iframe 可能处于三种状态还没开始加载、正在加载、已经加载完。你无法预知是哪种。如果父页面发消息时 iframe 还没加载完iframe.contentWindow可能是个初始的空窗口消息发过去也没人监听直接丢失。更糟的是如果 iframe 的src是动态设置的contentWindow在设置src之前指向的是about:blank你往这个窗口发消息等于发给了一个空白页。5.2 用握手解决时序问题最稳妥的方案是握手协议子页面加载完成后主动向父页面发一个CHILD_READY消息父页面收到后再下发初始化数据。这样无论谁先加载完通信都能正确建立。// 子页面加载完成后主动通知父页面 window.addEventListener(load, function() { window.parent.postMessage({ type: CHILD_READY }, https://parent.example.com); }); // 父页面收到 READY 后再下发数据 window.addEventListener(message, function(event) { if (event.origin ! https://child.example.com) return; if (event.data.type CHILD_READY) { event.source.postMessage( { type: PARENT_INIT, payload: { userId: 123 } }, https://child.example.com ); } });这个模式的好处是父页面不需要关心 iframe 什么时候加载完子页面也不需要关心父页面什么时候准备好。双方各自在合适的时机发消息由握手协议保证顺序。5.3 父页面先就绪的情况怎么处理如果父页面需要主动下发数据而子页面可能还没就绪可以反过来父页面在iframe.onload之后发消息。但onload只保证文档加载完子页面的 JS 初始化逻辑可能还没跑完。所以更稳的做法是父页面缓存待发消息等收到CHILD_READY再发。// 父页面维护一个待发消息队列 const pendingMessages []; function sendToChild(message) { const iframe document.getElementById(childFrame); if (childReady) { iframe.contentWindow.postMessage(message, https://child.example.com); } else { pendingMessages.push(message); } } // 收到 CHILD_READY 后把队列里的消息全部发出去 function onChildReady() { childReady true; const iframe document.getElementById(childFrame); pendingMessages.forEach(function(msg) { iframe.contentWindow.postMessage(msg, https://child.example.com); }); pendingMessages.length 0; }这个队列机制在实际项目里非常有用尤其是父页面有多个模块都要给子页面发消息的时候不用每个模块都去判断子页面是否就绪。6. 几个我踩过的真实坑与排查过程光讲原理不够我把几个印象深刻的坑完整还原一下包括怎么发现、怎么定位、怎么修复的。这些坑你在官方文档里基本看不到。6.1 坑一targetOrigin 写成*导致的安全告警有一次代码评审安全团队扫出来一个高危问题某处postMessage的targetOrigin写成了*。开发同学的理由是本地开发时域名不固定写*方便。这个理由在开发环境勉强能接受但代码合到主干、发到生产就是实打实的安全漏洞。排查过程很简单全局搜postMessage和*把所有命中点列出来逐个确认。修复方案是开发环境用环境变量注入当前域名生产环境写死具体源。如果确实需要支持多个源就根据当前环境动态计算targetOrigin而不是无脑用*。经验把targetOrigin的取值封装成一个函数根据环境返回不同的源。这样既方便开发又不会在生产环境留隐患。6.2 坑二消息监听器重复注册导致的内存泄漏有个页面用户反复打开关闭某个弹窗每次打开都会创建一个新的 iframe。结果用久了页面越来越卡最后崩溃。排查发现每次创建 iframe 时都注册了一个message监听器但关闭时没有移除。监听器越积越多每个消息都被处理 N 次性能直接崩掉。修复方案是注册监听器时保存引用销毁 iframe 时用removeEventListener移除。或者更简单全局只注册一个监听器在监听器内部根据event.source判断是哪个 iframe 发来的消息。// 全局只注册一次 window.addEventListener(message, handleMessage); function handleMessage(event) { // 通过 event.source 找到对应的 iframe 实例 const iframeInfo findIframeBySource(event.source); if (!iframeInfo) return; // 分发处理 }6.3 坑三结构化克隆失败导致消息发不出去有一次子页面要传一个包含Date对象和Map的复杂数据结构给父页面结果父页面收到的数据里Date变成了字符串Map直接丢了。原因是 postMessage 用的是结构化克隆算法它支持Date、Map、Set这些类型但不支持函数、DOM 节点、原型链上的自定义属性。更隐蔽的是如果消息里混入了不可克隆的对象postMessage会直接抛DataCloneError消息根本发不出去而且这个错误在发送方接收方完全无感。排查时要在发送方加 try-catchtry { targetWindow.postMessage(message, targetOrigin); } catch (err) { console.error(消息发送失败可能是数据不可克隆:, err, message); }修复方案是发送前把数据序列化成纯 JSON 结构接收方再反序列化。虽然损失了一些类型信息但胜在稳定可靠。6.4 坑四iframe 被重定向后 origin 变了有个场景iframe 的src指向一个会做重定向的地址最终落到另一个域名下。父页面按初始域名配置了targetOrigin结果消息发不出去因为 iframe 实际所在的源已经变了。接收消息时按初始域名校验event.origin也会把合法消息拦掉。这个坑的排查思路是在 iframe 里打印window.location.origin确认实际源是什么。修复方案是如果重定向是预期的就把最终源加入白名单如果重定向是非预期的就要检查重定向逻辑是不是有问题。7. 一套可直接复用的父子通信封装讲了这么多原理和坑最后给一套我实际项目里在用的封装。它把发送、接收、握手、来源校验、消息队列都包进去了父子页面各引一份改改配置就能用。7.1 父页面侧的封装class ParentBridge { constructor(iframeId, childOrigin) { this.iframe document.getElementById(iframeId); this.childOrigin childOrigin; this.childReady false; this.pendingMessages []; this.handlers {}; this.init(); } init() { window.addEventListener(message, (event) { if (event.origin ! this.childOrigin) return; const data event.data; if (!data || typeof data ! object) return; if (data.type CHILD_READY) { this.childReady true; this.flushPending(); return; } const handler this.handlers[data.type]; if (handler) { handler(data.payload, event.source); } }); } send(type, payload) { const message { type, payload }; if (this.childReady) { this.iframe.contentWindow.postMessage(message, this.childOrigin); } else { this.pendingMessages.push(message); } } flushPending() { this.pendingMessages.forEach((msg) { this.iframe.contentWindow.postMessage(msg, this.childOrigin); }); this.pendingMessages.length 0; } on(type, handler) { this.handlers[type] handler; } }7.2 子页面侧的封装class ChildBridge { constructor(parentOrigin) { this.parentOrigin parentOrigin; this.handlers {}; this.init(); } init() { window.addEventListener(message, (event) { if (event.origin ! this.parentOrigin) return; const data event.data; if (!data || typeof data ! object) return; const handler this.handlers[data.type]; if (handler) { handler(data.payload, event.source); } }); // 加载完成后通知父页面 window.addEventListener(load, () { window.parent.postMessage({ type: CHILD_READY }, this.parentOrigin); }); } send(type, payload) { window.parent.postMessage({ type, payload }, this.parentOrigin); } on(type, handler) { this.handlers[type] handler; } }7.3 使用示例父页面这样用const bridge new ParentBridge(childFrame, https://child.example.com); bridge.on(CHILD_SUBMIT, (payload) { console.log(收到子页面提交:, payload); // 处理完回结果 bridge.send(PARENT_SUBMIT_RESULT, { success: true }); }); // 随时可以发消息没就绪会自动排队 bridge.send(PARENT_INIT, { userId: 123 });子页面这样用const bridge new ChildBridge(https://parent.example.com); bridge.on(PARENT_INIT, (payload) { console.log(收到父页面初始化数据:, payload); }); bridge.on(PARENT_SUBMIT_RESULT, (payload) { console.log(提交结果:, payload); }); // 提交表单 bridge.send(CHILD_SUBMIT, { formData: { name: test } });这套封装的核心价值在于把时序问题、来源校验、消息队列这些容易出错的细节都藏起来了业务代码只需要关心发什么消息、收到消息做什么。父子页面各自独立通过消息协议解耦同源跨域都能用迁移时只改一个origin配置。7.4 几个使用时的注意事项第一childOrigin和parentOrigin一定要精确到协议、域名、端口不能省略端口。https://example.com和https://example.com:443在浏览器看来是同一个源但字符串比较时不一样建议统一写不带默认端口的形式。第二如果 iframe 的src是动态变化的每次变化后childReady要重置为false因为新加载的页面需要重新握手。第三消息处理函数里如果要做异步操作注意异常捕获别让一个 handler 的报错影响其他消息的处理。第四生产环境建议加个消息日志开关联调时打开上线后关闭方便排查问题又不影响性能。8. 关于 iframe 通信我最后想说的几句iframe 这个技术被很多人唱衰说什么要被微前端取代了。但现实是大量存量系统、第三方组件集成、老系统改造场景里iframe 依然是最省事、隔离性最好的方案。微前端框架再花哨底层很多也是靠 iframe 或者类似的隔离机制实现的。父子通信这件事核心就一句话把两个页面当成两个独立服务用消息协议通信而不是用方法调用耦合。想清楚这句话同源跨域都不是问题。我见过太多项目在这上面反复返工根本原因就是一开始图省事用了直接调用后面越改越乱。如果你现在正在做 iframe 相关的功能我的建议是先把消息协议表写出来再动手写代码。协议定好了父子两边的开发可以并行联调时对着协议表排查效率至少翻倍。另外postMessage的targetOrigin和event.origin校验从第一行代码就要写对别等到安全扫描报出来再补那时候改起来牵扯的面就大了。这套封装我在三个项目里用过从简单的表单嵌入到复杂的多级嵌套通信都扛得住。你可以直接拿去改也可以根据自己的业务裁剪。关键是理解背后的时序和校验逻辑这样遇到新问题才能自己定位而不是到处搜答案。 
长河君 · 2026/10/18 3:46:13 · 阅读 1.2k iframe父子通信实战：postMessage跨域方案与同源策略避坑指南
1. 从一次诡异的表单提交失败说起前阵子帮一个做后台管理系统的朋友排查问题现象特别邪门页面里嵌了一个 iframe里面加载的是另一个独立部署的表单页。用户在 iframe 里填完信息点提交主页面这边完全没反应控制台干干净净网络请求也没发出去。朋友一口咬定是后端接口挂了我让他把 iframe 单独在新标签页打开提交一切正常。问题就出在父子这两个字上。iframe 里的页面和外面的主页面在浏览器眼里是两个独立的文档环境各自有各自的window、document默认情况下它们之间是老死不相往来的。你在 iframe 里点按钮事件只在 iframe 内部冒泡外面那层根本感知不到。这不是 bug这是浏览器的安全设计。iframe实现父子内容通信说白了就是解决两个独立页面怎么互相喊话的问题。它看起来简单但真正落地时会牵扯到同源策略、跨域限制、消息格式约定、生命周期时序、内存泄漏等一堆细节。我见过太多项目在这上面翻车有的用window.parent直接调方法本地开发好好的一上线跨域就报Blocked a frame with origin...有的用postMessage但忘了校验来源埋下安全隐患还有的在 iframe 还没加载完就去通信拿到一堆undefined。这篇内容我打算把 iframe 父子通信这件事从头到尾捋一遍。不管你是刚接触 iframe 的新手还是被跨域通信折磨过的老手都能从里面找到能直接抄作业的方案。我会讲清楚同源和跨域两种场景分别怎么处理、postMessage的正确姿势、时序问题怎么规避、以及几个我踩过的真实坑。核心关键词就三个iframe 父子通信、postMessage、同源策略围绕它们展开。2. 先搞懂浏览器给 iframe 划的那条楚河汉界在动手写代码之前必须先把底层规则搞清楚否则你写的每一行通信代码都是碰运气。iframe 父子通信的所有坑根源都在浏览器的同源策略上。2.1 同源到底同的是什么同源策略里的源由三部分组成协议、域名、端口。三者完全一致才算同源。举个例子https://a.example.com和下面这些地址的关系是这样的对比地址是否同源原因https://a.example.com/page是协议、域名、端口全一致路径不影响http://a.example.com否协议不同https 对 httphttps://b.example.com否域名不同子域名也算不同源https://a.example.com:8080否端口不同默认 443 对 8080这里有个特别容易被忽略的点子域名之间默认也不同源。a.example.com和b.example.com在浏览器看来是两个完全不同的源哪怕它们指向同一台服务器。很多公司把主站和子系统部署在不同子域下结果 iframe 通信直接歇菜就是栽在这上面。同源的时候父子页面可以肆无忌惮地互相访问父页面能拿到iframe.contentWindow能读iframe.contentDocument能直接调 iframe 里定义的方法iframe 里也能通过window.parent反向操作父页面。这种模式下通信最省事但也是最容易写出耦合代码的地方。2.2 跨域时浏览器到底拦了什么跨域的时候浏览器不是把所有操作都拦死而是分层次的。理解这个层次你才知道哪些路能走、哪些路走不通。第一层DOM 访问被拦。父页面想读iframe.contentDocument跨域情况下直接抛异常报Blocked a frame with origin ... from accessing a cross-origin frame。你想拿到 iframe 里的某个元素、改个样式门都没有。第二层JS 对象访问被拦。父页面想调iframe.contentWindow.someMethod()同样被拦。反过来 iframe 想调window.parent.someMethod()也一样。但是有个例外window.parent、window.top、window.length这几个属性是允许访问的还有postMessage方法也是允许调用的。这几个漏网之鱼就是跨域通信的突破口。第三层网络请求不受同源策略直接限制。iframe 里发起的请求是 iframe 自己那个源的请求跟父页面没关系。父页面拦不住也管不着除非用 CSP 之类的策略。注意很多人以为跨域就是完全不能通信其实不是。浏览器留了postMessage这个官方通道专门用来做跨域通信。关键是要用对。2.3 为什么浏览器要这么设计理解设计动机你才能理解为什么有些歪招不能用。同源策略的核心目的是防止恶意页面窃取数据。设想一下如果没有同源策略你打开一个恶意网站它偷偷在页面里嵌一个 iframe 加载你的网银页面然后通过iframe.contentDocument读取你的账户信息、甚至模拟点击转账那就彻底乱套了。所以浏览器必须把不同源的文档环境隔离开。但隔离归隔离现实业务里确实有合法的跨域通信需求比如主站嵌一个第三方支付页面、嵌一个地图组件、嵌一个客服系统。于是postMessage应运而生它提供了一条受控的、需要双方显式配合的通信通道。你发消息要指定目标源收消息要校验来源源双方都同意才能通信。搞清楚了这层设计逻辑后面所有的代码写法就都顺理成章了。3. 同源场景能直接调但别调出一身债同源场景下父子通信是最简单的简单到很多人会滥用。我先把能用的方法列出来再讲讲为什么我不建议你随便用。3.1 父调子的几种写法父页面操作 iframe 里的内容核心是拿到contentWindow和contentDocument。假设页面里有个iframe idchildFrame src/child.html/iframe父页面可以这样写const iframe document.getElementById(childFrame); // 拿到 iframe 的 window 对象 const childWindow iframe.contentWindow; // 拿到 iframe 的 document 对象 const childDocument iframe.contentDocument || iframe.contentWindow.document; // 调用 iframe 里定义的方法 childWindow.doSomething(来自父页面的参数); // 直接操作 iframe 里的 DOM const childButton childDocument.getElementById(submitBtn); childButton.style.backgroundColor red;这里有个兼容性细节老版本 IE 需要用contentWindow.document现代浏览器contentDocument就够了。现在基本可以忽略 IE但如果你维护的是老系统加个||兜底没坏处。3.2 子调父的写法iframe 里反向操作父页面靠的是window.parent和window.top。parent是直接父级top是最顶层窗口。如果只有一层嵌套两者一样如果多层嵌套top会一路找到最外层。// 调用父页面的方法 window.parent.handleChildMessage(子页面发来的数据); // 操作父页面的 DOM window.parent.document.getElementById(status).innerText 子页面已就绪; // 如果嵌套多层想找最顶层 window.top.someGlobalMethod();3.3 直接调用为什么是个甜蜜的陷阱同源直接调用看起来很方便但我强烈建议你即使同源也优先用 postMessage。原因有三个都是血泪教训。第一个原因是耦合。父页面直接调childWindow.doSomething()意味着父页面必须知道子页面暴露了哪些方法、方法名叫什么、参数怎么传。子页面一改方法名父页面就崩。两个页面被死死绑在一起谁都不敢单独改。我见过一个项目父子页面是同源直接调用的后来子页面要独立部署到另一个域名下整个通信逻辑推倒重写改了两天。第二个原因是时序。iframe.contentWindow在 iframe 还没加载完的时候可能是个空壳或者不完整的状态。你直接调方法很可能报xxx is not a function。你得监听iframe.onload才能保证子页面就绪。但onload只保证文档加载完如果子页面里还有异步初始化逻辑onload触发时方法可能还没挂上去。这个时序问题在同源直接调用里特别难处理。第三个原因是迁移成本。今天同源明天可能就跨域了。业务发展过程中把子系统拆到独立域名下是常有的事。如果你一开始就用 postMessage跨域时几乎不用改代码如果用的是直接调用那就得全部重写。我的经验是把父子通信当成两个独立服务之间的接口来设计用消息传递而不是方法调用。这样无论同源还是跨域代码结构都一样迁移零成本。4. postMessage跨域通信的唯一正解postMessage是 HTML5 引入的跨文档通信 API专门解决不同源窗口之间的通信问题。它的设计很克制发送方指定目标窗口和目标源接收方校验来源源双方通过约定好的消息格式交换数据。4.1 发送消息的正确姿势发送消息用targetWindow.postMessage(message, targetOrigin, [transfer])。三个参数里前两个是必填的。// 父页面向 iframe 发消息 const iframe document.getElementById(childFrame); iframe.contentWindow.postMessage( { type: INIT, payload: { userId: 123 } }, https://child.example.com ); // iframe 向父页面发消息 window.parent.postMessage( { type: READY, payload: null }, https://parent.example.com );message参数可以是任意可结构化克隆的对象字符串、数字、对象、数组都行。但注意函数、DOM 节点、Error 对象这些不能传会直接抛异常。实际项目里我建议统一用对象格式带上type字段区分消息类型payload字段装数据这样扩展性好。targetOrigin参数是安全的关键。它指定了只有这个源的窗口才能收到消息。如果你写成*意味着任何源都能收到这在生产环境是绝对禁止的。因为如果父页面被恶意页面通过某种方式嵌了或者 iframe 被替换成了恶意页面你的敏感数据就泄露了。正确做法是写死具体的源比如https://child.example.com。4.2 接收消息与来源校验接收消息靠监听message事件window.addEventListener(message, function(event) { // 第一步校验来源源不通过直接返回 const allowedOrigins [https://child.example.com, https://parent.example.com]; if (!allowedOrigins.includes(event.origin)) { console.warn(收到未知来源的消息已忽略:, event.origin); return; } // 第二步解析消息 const data event.data; if (!data || typeof data ! object) { return; } // 第三步按类型分发处理 switch (data.type) { case INIT: handleInit(data.payload); break; case READY: handleReady(data.payload); break; default: console.warn(未知消息类型:, data.type); } });这里有几个细节必须强调。event.origin是发送方的源一定要校验而且要用白名单精确匹配不能用includes做模糊匹配。比如https://child.example.com和https://child.example.com.evil.com用includes判断前者会误判后者为合法。正确做法是event.origin https://child.example.com这种精确相等。event.source是发送方的窗口引用可以用来回消息。比如父页面收到 iframe 的消息后想回复可以用event.source.postMessage(...)这样不用再去查 iframe 元素。4.3 消息格式的约定比代码本身更重要我见过太多项目postMessage 的代码写得没问题但消息格式一团糟。父页面发{a: 1}子页面期望{data: {a: 1}}对不上就各种undefined。所以在动手写代码之前先把消息协议定下来。我一般会定一个这样的协议表消息 type发送方数据格式说明PARENT_INIT父{ userId, token }父页面初始化时下发用户信息CHILD_READY子{}子页面就绪请求初始化数据CHILD_SUBMIT子{ formData }子页面提交表单数据PARENT_SUBMIT_RESULT父{ success, message }父页面返回提交结果PARENT_RESIZE父{ height }父页面通知子页面调整高度协议定好之后双方各自实现自己的收发逻辑联调时对着协议表排查效率高很多。协议表最好写在文档里别只存在某个人脑子里。5. 时序问题为什么你的消息总是发早了postMessage 本身是异步的但比异步更麻烦的是时序。父页面和 iframe 是两个独立的加载过程谁先加载完、谁先初始化好是不确定的。我踩过最典型的坑就是父页面在DOMContentLoaded里就给 iframe 发消息结果 iframe 还没加载完消息石沉大海。5.1 父子加载顺序的不确定性设想一个场景父页面加载时iframe 的src指向一个子页面。父页面的 JS 执行到发消息那行时iframe 可能处于三种状态还没开始加载、正在加载、已经加载完。你无法预知是哪种。如果父页面发消息时 iframe 还没加载完iframe.contentWindow可能是个初始的空窗口消息发过去也没人监听直接丢失。更糟的是如果 iframe 的src是动态设置的contentWindow在设置src之前指向的是about:blank你往这个窗口发消息等于发给了一个空白页。5.2 用握手解决时序问题最稳妥的方案是握手协议子页面加载完成后主动向父页面发一个CHILD_READY消息父页面收到后再下发初始化数据。这样无论谁先加载完通信都能正确建立。// 子页面加载完成后主动通知父页面 window.addEventListener(load, function() { window.parent.postMessage({ type: CHILD_READY }, https://parent.example.com); }); // 父页面收到 READY 后再下发数据 window.addEventListener(message, function(event) { if (event.origin ! https://child.example.com) return; if (event.data.type CHILD_READY) { event.source.postMessage( { type: PARENT_INIT, payload: { userId: 123 } }, https://child.example.com ); } });这个模式的好处是父页面不需要关心 iframe 什么时候加载完子页面也不需要关心父页面什么时候准备好。双方各自在合适的时机发消息由握手协议保证顺序。5.3 父页面先就绪的情况怎么处理如果父页面需要主动下发数据而子页面可能还没就绪可以反过来父页面在iframe.onload之后发消息。但onload只保证文档加载完子页面的 JS 初始化逻辑可能还没跑完。所以更稳的做法是父页面缓存待发消息等收到CHILD_READY再发。// 父页面维护一个待发消息队列 const pendingMessages []; function sendToChild(message) { const iframe document.getElementById(childFrame); if (childReady) { iframe.contentWindow.postMessage(message, https://child.example.com); } else { pendingMessages.push(message); } } // 收到 CHILD_READY 后把队列里的消息全部发出去 function onChildReady() { childReady true; const iframe document.getElementById(childFrame); pendingMessages.forEach(function(msg) { iframe.contentWindow.postMessage(msg, https://child.example.com); }); pendingMessages.length 0; }这个队列机制在实际项目里非常有用尤其是父页面有多个模块都要给子页面发消息的时候不用每个模块都去判断子页面是否就绪。6. 几个我踩过的真实坑与排查过程光讲原理不够我把几个印象深刻的坑完整还原一下包括怎么发现、怎么定位、怎么修复的。这些坑你在官方文档里基本看不到。6.1 坑一targetOrigin 写成*导致的安全告警有一次代码评审安全团队扫出来一个高危问题某处postMessage的targetOrigin写成了*。开发同学的理由是本地开发时域名不固定写*方便。这个理由在开发环境勉强能接受但代码合到主干、发到生产就是实打实的安全漏洞。排查过程很简单全局搜postMessage和*把所有命中点列出来逐个确认。修复方案是开发环境用环境变量注入当前域名生产环境写死具体源。如果确实需要支持多个源就根据当前环境动态计算targetOrigin而不是无脑用*。经验把targetOrigin的取值封装成一个函数根据环境返回不同的源。这样既方便开发又不会在生产环境留隐患。6.2 坑二消息监听器重复注册导致的内存泄漏有个页面用户反复打开关闭某个弹窗每次打开都会创建一个新的 iframe。结果用久了页面越来越卡最后崩溃。排查发现每次创建 iframe 时都注册了一个message监听器但关闭时没有移除。监听器越积越多每个消息都被处理 N 次性能直接崩掉。修复方案是注册监听器时保存引用销毁 iframe 时用removeEventListener移除。或者更简单全局只注册一个监听器在监听器内部根据event.source判断是哪个 iframe 发来的消息。// 全局只注册一次 window.addEventListener(message, handleMessage); function handleMessage(event) { // 通过 event.source 找到对应的 iframe 实例 const iframeInfo findIframeBySource(event.source); if (!iframeInfo) return; // 分发处理 }6.3 坑三结构化克隆失败导致消息发不出去有一次子页面要传一个包含Date对象和Map的复杂数据结构给父页面结果父页面收到的数据里Date变成了字符串Map直接丢了。原因是 postMessage 用的是结构化克隆算法它支持Date、Map、Set这些类型但不支持函数、DOM 节点、原型链上的自定义属性。更隐蔽的是如果消息里混入了不可克隆的对象postMessage会直接抛DataCloneError消息根本发不出去而且这个错误在发送方接收方完全无感。排查时要在发送方加 try-catchtry { targetWindow.postMessage(message, targetOrigin); } catch (err) { console.error(消息发送失败可能是数据不可克隆:, err, message); }修复方案是发送前把数据序列化成纯 JSON 结构接收方再反序列化。虽然损失了一些类型信息但胜在稳定可靠。6.4 坑四iframe 被重定向后 origin 变了有个场景iframe 的src指向一个会做重定向的地址最终落到另一个域名下。父页面按初始域名配置了targetOrigin结果消息发不出去因为 iframe 实际所在的源已经变了。接收消息时按初始域名校验event.origin也会把合法消息拦掉。这个坑的排查思路是在 iframe 里打印window.location.origin确认实际源是什么。修复方案是如果重定向是预期的就把最终源加入白名单如果重定向是非预期的就要检查重定向逻辑是不是有问题。7. 一套可直接复用的父子通信封装讲了这么多原理和坑最后给一套我实际项目里在用的封装。它把发送、接收、握手、来源校验、消息队列都包进去了父子页面各引一份改改配置就能用。7.1 父页面侧的封装class ParentBridge { constructor(iframeId, childOrigin) { this.iframe document.getElementById(iframeId); this.childOrigin childOrigin; this.childReady false; this.pendingMessages []; this.handlers {}; this.init(); } init() { window.addEventListener(message, (event) { if (event.origin ! this.childOrigin) return; const data event.data; if (!data || typeof data ! object) return; if (data.type CHILD_READY) { this.childReady true; this.flushPending(); return; } const handler this.handlers[data.type]; if (handler) { handler(data.payload, event.source); } }); } send(type, payload) { const message { type, payload }; if (this.childReady) { this.iframe.contentWindow.postMessage(message, this.childOrigin); } else { this.pendingMessages.push(message); } } flushPending() { this.pendingMessages.forEach((msg) { this.iframe.contentWindow.postMessage(msg, this.childOrigin); }); this.pendingMessages.length 0; } on(type, handler) { this.handlers[type] handler; } }7.2 子页面侧的封装class ChildBridge { constructor(parentOrigin) { this.parentOrigin parentOrigin; this.handlers {}; this.init(); } init() { window.addEventListener(message, (event) { if (event.origin ! this.parentOrigin) return; const data event.data; if (!data || typeof data ! object) return; const handler this.handlers[data.type]; if (handler) { handler(data.payload, event.source); } }); // 加载完成后通知父页面 window.addEventListener(load, () { window.parent.postMessage({ type: CHILD_READY }, this.parentOrigin); }); } send(type, payload) { window.parent.postMessage({ type, payload }, this.parentOrigin); } on(type, handler) { this.handlers[type] handler; } }7.3 使用示例父页面这样用const bridge new ParentBridge(childFrame, https://child.example.com); bridge.on(CHILD_SUBMIT, (payload) { console.log(收到子页面提交:, payload); // 处理完回结果 bridge.send(PARENT_SUBMIT_RESULT, { success: true }); }); // 随时可以发消息没就绪会自动排队 bridge.send(PARENT_INIT, { userId: 123 });子页面这样用const bridge new ChildBridge(https://parent.example.com); bridge.on(PARENT_INIT, (payload) { console.log(收到父页面初始化数据:, payload); }); bridge.on(PARENT_SUBMIT_RESULT, (payload) { console.log(提交结果:, payload); }); // 提交表单 bridge.send(CHILD_SUBMIT, { formData: { name: test } });这套封装的核心价值在于把时序问题、来源校验、消息队列这些容易出错的细节都藏起来了业务代码只需要关心发什么消息、收到消息做什么。父子页面各自独立通过消息协议解耦同源跨域都能用迁移时只改一个origin配置。7.4 几个使用时的注意事项第一childOrigin和parentOrigin一定要精确到协议、域名、端口不能省略端口。https://example.com和https://example.com:443在浏览器看来是同一个源但字符串比较时不一样建议统一写不带默认端口的形式。第二如果 iframe 的src是动态变化的每次变化后childReady要重置为false因为新加载的页面需要重新握手。第三消息处理函数里如果要做异步操作注意异常捕获别让一个 handler 的报错影响其他消息的处理。第四生产环境建议加个消息日志开关联调时打开上线后关闭方便排查问题又不影响性能。8. 关于 iframe 通信我最后想说的几句iframe 这个技术被很多人唱衰说什么要被微前端取代了。但现实是大量存量系统、第三方组件集成、老系统改造场景里iframe 依然是最省事、隔离性最好的方案。微前端框架再花哨底层很多也是靠 iframe 或者类似的隔离机制实现的。父子通信这件事核心就一句话把两个页面当成两个独立服务用消息协议通信而不是用方法调用耦合。想清楚这句话同源跨域都不是问题。我见过太多项目在这上面反复返工根本原因就是一开始图省事用了直接调用后面越改越乱。如果你现在正在做 iframe 相关的功能我的建议是先把消息协议表写出来再动手写代码。协议定好了父子两边的开发可以并行联调时对着协议表排查效率至少翻倍。另外postMessage的targetOrigin和event.origin校验从第一行代码就要写对别等到安全扫描报出来再补那时候改起来牵扯的面就大了。这套封装我在三个项目里用过从简单的表单嵌入到复杂的多级嵌套通信都扛得住。你可以直接拿去改也可以根据自己的业务裁剪。关键是理解背后的时序和校验逻辑这样遇到新问题才能自己定位而不是到处搜答案。