iframe如何调用父页面js，常见方法有哪些？

iframe调用父页面js的核心实现是：同域下通过contentWindow直接调用，跨域下通过postMessage消息机制传递。 许多前端开发者问我，iframe怎么调用父页面js，其实并不复杂，但很多人卡在跨域报错上，这篇文章用一个实际项目经验的视角，把同域、跨域、特殊情况下的调用方式一次讲透。

iframe怎么调用父页面js：先分清同域和跨域

在说具体代码之前，先明确一个基本概念，iframe像是一个寄生在父页面里的独立小窗口，它和父页面的关系取决于同源策略（协议、域名、端口三者一致才算同源）。

同域场景下的直接调用方式

同一个域名下，两个页面之间的通信不受限制，假设父页面地址是 https://www.example.com/a.html，iframe嵌入的是 https://www.example.com/b.html，此时iframe页面可以直接通过 window.parent 拿到父页面的window对象。

父页面代码：

// 父页面定义一个函数
function parentSay(msg) {
  console.log('父页面收到消息：' + msg);
  document.getElementById('result').innerText = msg;
}

iframe内页代码：

// 直接调用父页面函数
window.parent.parentSay('我是iframe里的页面');
// 也可以直接操作父页面的DOM
window.parent.document.getElementById('header').style.display = 'none';

这里有个细节容易踩坑，如果你在iframe里直接写 parent.parentSay()，省略了 window. 前缀，在大多数浏览器里也能跑通，但在严格模式或某些安全策略下可能会报错，规范写法是 window.parent 或 window.top，top 代表最顶层的window对象，如果iframe嵌套了两层，用 parent 只能拿到上一级的window，用 top 才能拿到最顶层的那个。

同域调用的三个安全前提

直接调用并不是任何时候都有效,需要满足以下条件：

• iframe和父页面属于同一个域名和协议（https或http必须一致）
• iframe的当前文档没有设置 sandbox 属性（sandbox会隔离脚本执行）
• 父页面没有设置 X-Frame-Options 或 Content-Security-Policy 拒绝被嵌入

行业共识认为，如果以上任意一条不满足，直接调用就会失败，浏览器控制台会给出明确的错误提示，比如sandbox属性如果加了 allow-scripts 而没有加 allow-same-origin，即使域名相同,浏览器也会把它当跨域处理。

iframe跨域调用父页面方法：postMessage是靠谱方案

跨域情况下，window.parent 只能拿到一个被包裹的引用，直接调用函数会抛出 Uncaught DOMException: Blocked a frame from accessing a cross-origin frame 报错，解决跨域调用，用 window.postMessage 是业界标准方案。

postMessage双向通信完整代码

父页面需要做两件事：监听消息、接收消息后执行操作。

// 父页面
window.addEventListener('message', function(event) {
  // 安全校验：校验来源域名
  if (event.origin !== 'https://child.example.com') {
    return;
  }
  // 处理iframe发来的消息
  if (event.data && event.data.type === 'CALL_PARENT') {
    parentSay(event.data.payload);
  }
});
function parentSay(msg) {
  document.getElementById('fromIframe').textContent = msg;
}

iframe内页代码：

// iframe内页发送消息给父页面
window.parent.postMessage({
  type: 'CALL_PARENT',
  payload: '这是跨域iframe发来的数据'
}, 'https://www.example.com');

这里有两个关键点，第一个是第二个参数务必写成父页面的具体地址，不要写 ，写 代表允许发送到任何页面，这在生产环境属于相当危险的操作，如果父页面地址被恶意站点替换，数据就直接泄露了，第二个是父页面里一定要校验 event.origin,确保消息来源可信。

同样是跨域调用，为什么不推荐location.hash或window.name

有些旧项目里还能看到用 location.hash 改URL来传数据、用 window.name 跨域存储数据的做法,这两种方式目前已经处于被淘汰的边缘：

• location.hash 传参会出现在地址栏里，长度也受限，传大数据基本不可行
• window.name 存储：能存较长字符串，但刷新页面时会保留上次的值，容易造成数据串用

对于iframe调用父页面方法这种需求，postMessage一个方案就覆盖了，不需要再考虑技术债遗留方案，很多老前端在维护旧代码时会碰到这两种写法，能看懂即可,新代码统一用postMessage。

同一个iframe嵌入多个父页面：复用时的作用域陷阱

很多后台管理系统有这样一个需求：同一个菜单模块被嵌到不同父页面里，iframe内页要能识别自己是挂在哪个父页面下面，有的开发者直接复制iframe代码就完事，结果发现每个父页面调用的内容都一样,问题就出在作用域上。

如何让iframe知道自己属于哪个父页面

给iframe加一个自定义属性来传递身份标识，是最直观的方式,嵌入时：

<iframe src="https://child.example.com/module.html" data-parent-id="dashboard"></iframe>

iframe内页读取：

var parentId = window.frameElement ? window.frameElement.getAttribute('data-parent-id') : 'unknown';
window.parent.postMessage({
  type: 'REGISTER',
  parentId: parentId
}, 'https://www.example.com');

这里用到了 window.frameElement，它返回iframe在父页面中的DOM元素引用，注意，这个API只在同域下可用，跨域情况下会返回null，跨域场景就用postMessage把身份信息传给父页面,让父页面来判断来自哪个模块。

需要注意嵌套层级的问题，iframe内页如果又嵌套了子iframe，window.frameElement 拿到的是中间层iframe的元素，拿不到最外层的元素，这就需要在每一层传参时都把身份信息往上传,最终由最外层父页面统一处理。

后台管理系统iframe模块调用父页面js的完整操作路径

结合上文的实现逻辑，具体落地到后台管理系统里,整体操作路径分为三步。

第一步：确认目标iframe页面是内嵌还是独立访问

网上很多教程只讲怎么写代码，没有提过这个认知前置，后台系统里的iframe页面通常既能内嵌到框架中，也能用浏览器单独打开调试，这种情况下，如果页面是独立打开的，window.parent === window,直接调用父页面方法是无效的。

建议在代码里加一个环境判断：

if (window.parent === window) {
  console.log('当前是独立打开状态，跳过调用父页面逻辑');
} else {
  // 正常调用父页面
}

这不是防御式编程，而是后台系统实际场景里必然会遇到的状况，开发时独立调试页面、测试时单独打开页面都是常规操作。

第二步：按场景选择通信方案

先看一张对比表,按实际场景选方案：

但凡涉及跨域全部归入postMessage一类，不必再去想别的办法，逻辑简单,维护成本低。

第三步：调试调用是否成功

在控制台验证调用是否生效，有两种方式，同域场景可以直接在iframe页面控制台输入 window.parent.父函数名，如果能打印出函数定义，说明引用成功,跨域场景在父页面控制台监听message事件：

window.addEventListener('message', function(e) {
  console.log('捕获到消息：', e.origin, e.data);
});

在iframe页面发送消息后看父页面控制台是否打印日志，排查范围可控,比盲目改代码快得多。

父页面主动调用iframe内页js的反向操作

有iframe调用父页面，自然有父页面调用iframe内页的情况，后台系统表单联动就是典型的需求，这类需求里，iframe本身不一定需要主动调父页面，但父页面要能触发iframe里的函数,实现思路也要清楚。

同域下通过 iframe.contentWindow 获取内页的window对象,然后直接调用函数：

var frame = document.getElementById('myFrame');
frame.contentWindow.childFunction('参数');

跨域下父页面通过 iframe.contentWindow.postMessage 发消息给iframe页面：

document.getElementById('myFrame').contentWindow.postMessage({
  type: 'TRIGGER_CHILD',
  payload: '参数'
}, 'https://child.example.com');

iframe内页监听：

window.addEventListener('message', function(event) {
  if (event.origin !== 'https://www.example.com') return;
  if (event.data.type === 'TRIGGER_CHILD') {
    childFunction(event.data.payload);
  }
});

这样父子页面的双向通信就都打通了，整体逻辑并不复杂：跨域一律走postMessage，同域直接引用window对象，庞大的纯前端调用方案里，很多看起来高级的封装,底层就是这两条路没有第三条路。

iframe内容嵌入后台系统有几年经验的前端开发者，基本都出过同类型的bug，要么是直接调用时不判断环境，页面崩在 window.parent 为null上；要么是跨域时没校验origin，数据来源被伪造，这些坑不算知识盲区,但确实很容易在忙起来时忽略。

iframe调用父页面js的过程中，安全问题依然是重点，运营后台系统如果涉及权限信息传递，消息里绝对不能带敏感凭据，最好由父页面做身份判定，iframe只发业务事件通知，具体场景下用什么方案，用postMessage还是直接用contentWindow，核心只看跨不跨域,这也是这篇文章最想告诉你的一条主线。