企业官网建设流程全解析

1. 跨域通信的场景与原理拆解

1.1 为什么父子窗口跨域通信这么难

做前端时间长了，很难绕开 iframe 这个老伙计。无论是把报表系统嵌进管理后台，还是在主站里挂一个第三方业务模块，只要页面结构里出现 iframe，跨域通信这个问题迟早要找上门。网上聊 iframe 通信的帖子不少，但很多都只讲一个 postMessage，遇到同域直取、hash 传值、window.name 这些场景时，不少人会卡在“怎么还有这种玩法”这一步。

先说清楚一个核心概念：浏览器同源策略。它要求页面只能访问同协议、同域名、同端口下的资源。只要 iframe 的 src 域名和父页面不同，父页面里的 JavaScript 就不能直接读取子页面里的 DOM，子页面里的代码也不能随意触碰父页面的 window 对象。这套规则本身是为了安全，但它在隔离恶意脚本的同时，也把正常业务通信的门给锁上了。

实际业务里，嵌入的 iframe 往往不是自己能随手改的。比如企业级报表系统、第三方支付回调页、不同团队维护的业务前台，域名不可能完全统一。这时候父子双方要交换登录态、筛选条件、跳转指令，就必须在不突破浏览器安全边界的前提下想办法。这四种方法恰好覆盖了不同场景下的通信需求：

• postMessage：跨域通信的首选，官方标准 API，双向传递，支持复杂数据结构。
• 同域直取：父子同域时最简单直接的方式，但跨域时完全失效。
• URL hash 传值：不需要额外 API，利用浏览器地址变化机制做轻量级信号传递。
• window.name 传值：利用窗口对象属性在导航后仍然保留的特性，适合一次性传少量数据。

这四种不是互相替代的关系，而是按场景互补。我在实际项目里就有过这样的经历：小页面用 hash 足够，复杂业务必须上 postMessage，而偶尔遇到第三方页面没法改代码的情况，window.name 又能救急。下面按我推荐的程度逐个拆开聊。

1.2 四种方案的选型思路

在详细展开代码之前，先给一个粗粒度的判断标准，免得读者在错误的方向上浪费时间。

如果你的业务场景是父子双方代码都是自己的、可以随时部署，那方案一 postMessage 是绝对优先选择。它功能最完整、安全性最好、数据结构支持比字符串更丰富，浏览器兼容性也能覆盖到 IE8 以上的绝大多数环境。

如果父子同域，只是分开部署在不同目录下，那方案二直取 DOM 反而比 postMessage 省事。你可以直接调用子页面里的函数、读取子页面变量，代码写起来像操作普通 DOM 一样顺手。但注意，一旦域名不一致，这套方式会立刻抛错，而且没有兜底余地。

如果iframe 的 src 指向的是一个不能改代码的第三方页面，或者你只想单向传一个“通知类”的信号，比如告诉子页面“筛选条件变了请刷新”，那方案三 URL hash 就够用了，它不依赖对端任何 JS 逻辑。

window.name 我一般在两种情况下用：一是父页面和子页面跨域但子页面内部要跳转到另一个同域名地址，想在跳转前后保留数据；二是某些极老旧的浏览器环境，postMessage 支持不完善，需要兜底。它不像 hash 那样会污染历史记录，也不会触发 hashchange 事件，算是一个比较“安静”的通道。

接下来我的惯例是先给结论再给代码，讲清楚每种方案的原理、适合谁、有什么坑，最后再统一做对比表，方便你对照着做决策。

2. 方法一：postMessage——跨域通信的正统答案

2.1 postMessage 的 API 与 targetOrigin 参数

postMessage 是 HTML5 提供的跨文档通信 API，接口看起来简单，就两个关键用法。

发消息的一方调用targetWindow.postMessage(message, targetOrigin)。targetWindow 是你要发送目标的 window 对象，在父子窗口场景里，父页面要拿到iframe.contentWindow，子页面要拿到window.parent。message 参数可以传字符串，也可以传结构化克隆支持的各种对象，数组、普通对象都能直接传。targetOrigin 写目标窗口的源，格式是协议 + 域名 + 端口，比如https://example.com。这个参数必须认真对待，它决定了浏览器会不会真的把消息投递出去。

接收消息的一方通过window.addEventListener('message', handler)来监听。handler 收到的 event 对象里有几个关键字段：event.data是消息内容，event.origin是发送方的源，event.source是发送方 window 对象。这里最容易被忽略的一点是：你必须在 handler 里校验 event.origin，否则任何页面都能往你这个窗口塞消息，轻则数据错乱，重则被恶意脚本利用。

targetOrigin 之所以重要，是因为如果你把它写成*，意味着不关心消息发给谁，也不会做源校验。在实际项目中，我要求团队里的所有 postMessage 调用，targetOrigin 必须写具体域名，除非是纯本地 demo 或者开发环境。这不是矫情，而是每一次漏写，都可能变成一个安全漏洞。

老规矩，先看一个最小可用示例。父页面：

<!-- 父页面 parent.html --> <iframe id="childFrame" src="https://child.example.com/child.html" style="width: 600px; height: 400px;"></iframe> <script> const iframe = document.getElementById('childFrame'); // 等 iframe 加载完成后发送消息 iframe.onload = function () { iframe.contentWindow.postMessage({ type: 'AUTH_TOKEN', token: 'abc123', userId: 10086 }, 'https://child.example.com'); }; // 接收子页面回传的消息 window.addEventListener('message', function (event) { // 校验消息来源，防止陌生页面冒充 if (event.origin !== 'https://child.example.com') return; console.log('父页面收到消息：', event.data); }); </script>

子页面：

<!-- 子页面 child.html --> <script> // 接收父页面的消息 window.addEventListener('message', function (event) { // 同样要校验来源 if (event.origin !== 'https://parent.example.com') return; console.log('子页面收到消息：', event.data); // 处理完成后回传消息给父页面 event.source.postMessage({ type: 'AUTH_RESULT', success: true }, 'https://parent.example.com'); }); </script>

这段代码基本就是跨域父子通信的标准骨架。子页面里回传消息时直接用了event.source，省去了单独获取父窗口引用的麻烦，而且这是最可靠的方式，因为消息就是从那个窗口发来的。

2.2 父传子、子传父的完整实现

上面的示例已经展示了基础的父子双向通信。但在实际业务里，消息结构要从一开始就规划好，否则项目一复杂就乱套。我在自己项目里习惯给消息定义一个统一格式，至少包含 type 和 payload 两个字段。

// 统一消息格式约定 { type: 'LOGIN_SUCCESS', // 消息类型，用大写下划线语义化命名 requestId: 'uuid-xxxx', // 可选，用于关联请求和响应 payload: { // 真正的数据内容 username: 'admin', role: 'operator' } }

type 字段用来区分业务语义，比如AUTH_TOKEN、FILTER_CHANGED、NAVIGATE。payload 放具体数据。requestId 在需要请求-响应模式时很重要，比如父页面发一个“查询订单详情”的消息，子页面处理完回传时带上同一个 requestId，父页面才能知道这条响应对应哪一次请求。在不需要异步关联的场景下可以省掉，但存在总比没有好。

我还见过一种更省事的写法：子页面直接把函数名称通过 message 传出去，父页面收到后调用对应函数。这种方式在小型工具型页面里很常见，但维护起来比较费劲，一旦函数目录和消息类型对不上，排查时要翻两层代码。所以我更推荐用 type 驱动一套集中式的消息分发机制：

// 子页面：消息分发器 const messageHandlers = { 'AUTH_TOKEN': function (payload, sourceWindow) { // do something with payload }, 'FILTER_CHANGED': function (payload, sourceWindow) { // update local state } }; window.addEventListener('message', function (event) { if (event.origin !== 'https://parent.example.com') return; const { type, payload } = event.data || {}; if (!type || !messageHandlers[type]) return; messageHandlers[type](payload, event.source); });

这种写法等于在前端内部做了一层轻量级消息路由。新业务来的时候，只需要在 messageHandlers 里加一个处理函数，不需要再往监听器里堆 if-else，代码可读性和可维护性会提升一大截。父页面那端也可以做同样的设计，两边消息类型就成了一份隐式协议。

2.3 安全校验：origin 白名单不能省

前面反复提 origin 校验，这里展开说说为什么它值得单独占一节。

如果你不做 origin 校验，任何恶意页面都可以在自己的页面里创建一个指向你页面的 iframe，然后往你的 iframe 里 postMessage 任意内容。如果你的监听器里直接在 message.data 基础上执行操作，比如根据传过来的 URL 做跳转、根据传过来的配置修改敏感字段，那攻击者就能顺着这条通道撬开你的业务逻辑。

干净的校验写法是维护一个白名单，而不是写一长串 if-else：

// 允许通信的源白名单 const ALLOWED_ORIGINS = [ 'https://parent.example.com', 'https://admin.example.com' ]; window.addEventListener('message', function (event) { if (!ALLOWED_ORIGINS.includes(event.origin)) return; // 后续业务处理 });

有人会问，能不能校验 event.source 而不是 origin？其实两者是两码事：origin 是发送方的“户籍”，source 是发送方窗口的“身份证”。在事件回调里校验 origin 已经足够，source 更多是用来回信的。另外别忘了，如果页面嵌入的环境比较特殊，比如内部管理系统挂在某台内网服务器上，origin 里的端口也要对得上，http://192.168.1.10:8080和http://192.168.1.10就是两个完全不同的源。

还有一个小坑：postMessage 虽然支持传对象，但对象的原型链会丢失。也就是说，你传一个 Date 对象过去，对端收到的不是 Date 实例，而是一个结构类似的普通对象；传 RegExp 类型也一样。如果你需要保存类型信息，最好在发送前手工序列化，或者在消息格式里增加一个 type 声明，接收时根据声明做转换。

3. 方法二：同域下的 contentWindow / contentDocument 直接访问

3.1 同域直接访问的原理与适用边界

如果父子页面在同一个域名下，事情就简单得多。同源策略允许父页面直接通过 iframe 的 contentWindow 拿到子页面的 window 对象，也允许子页面通过 parent 或 top 拿到父页面的 window 对象。拿到 window 之后，不仅能读变量、调用函数，还能直接操作对方文档里的 DOM。这种方式的通信效率最高，也不需要走事件通道，代码写起来像操作同一个页面里的元素。

适用范围有一个前提：父子页面必须完全同源。这里说的同源是协议、域名、端口全部一致，只要是同源，哪怕子页面路径和父页面完全不同也没关系。很多公司内部的单点登录系统就喜欢把各类业务系统都挂在同一个主域名下，用不同的子路径或者子域名加端口区分，这时候父子 iframe 之间通信用直取最省心。

举个例子，父页面在https://app.example.com/main.html，iframe 加载的是https://app.example.com/modules/report.html，两者协议、域名、端口一模一样，就是不同路径，那直取完全没问题。如果 iframe 加载的是https://report.example.com/report.html，虽然域名长得相似，但已经不是同一个源，直取会直接被拦截。

3.2 父页面操作子页面：DOM、函数、变量

父页面拿到 iframe 元素之后，用 contentWindow 就能直达子页面的 window 对象，用 contentDocument 则能拿到子页面的 document。

// 父页面 parent.html const iframe = document.getElementById('childFrame'); // 方式一：通过 contentWindow 调用子页面定义的函数 iframe.contentWindow.myFunction('hello'); // 方式二：读取子页面全局变量 console.log(iframe.contentWindow.globalConfig); // 方式三：操作子页面 DOM iframe.contentDocument.getElementById('reportTitle').textContent = '月度报表'; iframe.contentDocument.querySelectorAll('.row').forEach(row => { row.style.backgroundColor = '#f7f7f7'; });

这种直接操作的能力在实际业务里非常香。常见场景是父页面点一个按钮，直接修改子页面的筛选条件并触发子页面的刷新逻辑。因为子页面的函数就在那里，父页面一行代码调用即可。你可能需要等 iframe 加载完成再调用子页面的函数，最简单的检查方式是轮询 contentWindow 上是否已经有对应函数，或者直接用 iframe.onload 时机触发。

子页面的 DOM 操作也同样直接。比如父页面需要给子页面内某个报表容器填一个登录用户名，用 contentDocument 查一下再赋值就行。需要注意，这种权限大的同时也要求你对子页面结构足够了解，一旦子页面改版导致 DOM 结构变化，父页面里写死的选择器就会失效，所以我在项目里一般优先调用子页面暴露的函数，而不是直接操作 DOM。函数比 DOM 结构稳定得多，对外暴露一个稳定函数，等于给子页面留了一个可控的接口。

3.3 子页面操作父页面：parent / top 访问链

子页面往上访问时，用 window.parent 可以拿到直接父窗口，用 window.top 可以拿到最顶层的窗口。层级嵌套不深时，两者没区别；但如果你做了两层 iframe 嵌套，parent 只是上一层窗口，top 才是真正的主窗口。

// 子页面 child.html // 访问父页面全局函数 window.parent.parentFunction('from child'); // 读取父页面变量 console.log(window.parent.someGlobalVariable); // 如果只有一层 iframe，也可以用 top，效果相同 console.log(window.top.someGlobalVariable); // 访问父页面 DOM window.parent.document.getElementById('statusBar').textContent = 'done';

这种反向访问，气人的地方在于它没有触发事件或回调，纯靠全局对象可达性，所以在跨域通信的设计里很多团队干脆放弃使用它，全用 postMessage 做了统一封装。我的建议是：如果你就在同域环境下，直取明显更简单；但给子页面暴露函数时，要在命名上做区隔，避免全局变量命名冲突。因为父页面和子页面的 window 是上下级关系，同名变量一旦冲突，排查起来非常痛苦。

一个小经验：在子页面向父页面暴露接口时，把方法挂在一个命名空间对象底下，比如window.childBridge = { refresh, exportData, setFilter }。这样父页面调用就是iframe.contentWindow.childBridge.refresh()，既清晰又能减少全局污染。

3.4 跨域时强行访问会发生什么

很多新手的困惑是：我明明写对了代码，为什么在控制台报错说“Blocked a frame with origin ... from accessing a cross-origin frame”。这个错误就是浏览器同源策略的拦截机制在起作用，代码层面的表现是当你试图访问跨域 iframe 的 contentWindow 属性时，浏览器会抛出一个 SecurityError，或者干脆把相关属性变成 undefined。

实际开发中，我见过有人尝试用 try-catch 把这个错误吞掉，然后在 catch 里慢慢摸索别的办法。这个方法不算错，但不推荐把它当作正式方案，因为它解决不了根本问题，只是把错误延后了。更常见的做法是：在初始化时先判断父子是否同源，如果同源就直接用直取方案，否则自动降级到 postMessage。项目里可以写一个简单的工具函数：

function getChildWindowAccessible(iframe) { try { const doc = iframe.contentDocument; // contentDocument 在跨域情况下会直接变成 null if (doc) { return 'same-origin'; } } catch (e) { // 跨域时会抛 SecurityError } return 'cross-origin'; }

这个判断可以放在页面初始化时执行一次，然后根据返回值决定走哪条通信通道。我还遇到过一个坑：有些浏览器在跨域时会抛出错误，while 某些旧版浏览器返回的是 undefined，表现不一致。所以不要把这个判断函数当成通用的跨浏览器兼容方案，它更多是一个“预检手段”，真正保险的做法还是从一开始就明确知道自己的部署域名是什么。

4. 方法三：URL Hash 传值——轻量级通信的稳妥方案

4.1 Hash 传值的基本原理

URL 的 hash 部分，也就是#后面的内容，有一个特殊性：它不会触发页面重新加载。只要修改一个窗口的 location.hash，页面不会刷新，只有 URL 变了，而且会触发 hashchange 事件。利用这个特性，父子窗口之间可以互相修改对方的 location.hash 来传递消息，所以它成了跨域通信里一个不需要服务端配合的轻量方案。

原理上，父页面可以直接修改 iframe 的 src 属性里的 hash 部分，或者更直接地设置iframe.contentWindow.location.hash。子页面的 hash 发生变化时，会触发子页面的 hashchange 事件，子页面就收到了消息。反过来，子页面要发消息给父页面时，则是修改自己的 location.hash，让父页面去监听 iframe 的 src 变化。这里有个关键点：跨域情况下，子页面是无法直接修改父页面 location 的，但父页面可以修改子页面 iframe 的 src。

这个方案的好处是对第三方页面很友好，因为它完全不依赖对方 JavaScript 代码。只要对方的页面有监听 hashchange 的能力（或者对方本来就会根据 hash 参数去加载内容），你就能通过改 iframe src 来给它传参。很多开放平台就是用这种机制来做第三方嵌入页的初始化参数的。

4.2 父子双向 Hash 通信的完整流程

父页面向子页面传值，最简单的方式是直接在 iframe 的 src 里带上 hash，子页面加载时读取自己的 location.hash 即可：

<iframe src="https://child.example.com/report.html#token=abc123&type=month"></iframe>

子页面读取：

// 子页面 child.html function parseHash() { const hash = window.location.hash.replace(/^#/, ''); const params = {}; hash.split('&').forEach(pair => { const [key, value] = pair.split('='); params[key] = value; }); return params; } const initParams = parseHash(); console.log(initParams.token); // abc123

如果页面已经加载完成，父页面想动态传值，可以直接修改 iframe 的 src。注意这时候不要加完整 src，因为只要改变 hash 部分就会触发子页面的 hashchange：

// 父页面动态修改 const iframe = document.getElementById('childFrame'); iframe.src = iframe.src.split('#')[0] + '#token=xyz789&type=year';

子页面监听 hashchange：

// 子页面监听 window.addEventListener('hashchange', function () { const params = parseHash(); // 处理新参数 console.log('收到新参数：', params); });

子页面向父页面传递消息呢？因为子页面不能直接修改父页面 URL，但可以修改自己的 location.hash。它的 hash 一旦变化，父页面如果监听了 iframe 的 load 事件或者“hashchange 事件”？这里要小心：父页面监听的是 iframe.contentWindow 的 hashchange，跨域情况下父页面通常拿不到这个事件。但父页面可以监听 iframe 的 src 变化，用轮询或者 MutationObserver 监听 iframe.src 属性的变化。

// 父页面：轮询子页面 hash 变化 let lastHash = iframe.contentWindow.location.hash; setInterval(() => { const currentHash = iframe.contentWindow.location.hash; if (currentHash !== lastHash) { lastHash = currentHash; console.log('子页面 hash 变化：', currentHash); } }, 200);

轮询不是好方案，但在跨域且无法使用 postMessage 的场景下是唯一可靠的办法。200ms 的间隔足够覆盖多数业务需求，也不会太消耗性能。

4.3 Hash 方案的坑与适用边界

第一个坑是 hash 里不能直接传中文或特殊字符，需要 encodeURIComponent 编码一下，接收端再 decodeURIComponent 解码。传 JSON 数据时，先 JSON.stringify，再编码，否则 URL 会乱掉。

// 发送方编码 const data = JSON.stringify({ name: '张三', age: 18 }); const encoded = encodeURIComponent(data); iframe.src = iframe.src.split('#')[0] + '#' + encoded; // 接收方解码 window.addEventListener('hashchange', function () { const raw = window.location.hash.replace(/^#/, ''); const decoded = decodeURIComponent(raw); const data = JSON.parse(decoded); console.log(data.name); // 张三 });

第二个坑是 hash 传递的数据量有限，URL 长度一般在几千字符以内，超出后会截断或者被浏览器拒绝。所以它只适合传递短小的标识符，比如 id、页码、筛选关键字，不适合传大对象。

第三个坑是哈希变化会在浏览器历史记录里留下痕迹，用户按后退键时可能会回到上一个 hash 状态，导致页面状态闪变。我在做单页应用嵌入报表时，就遇到过用户按返回键之后，报表筛选条件莫名其妙变回旧值的情况。后来我在 iframe 通信里尽量用 replace 方式去改 hash，少用赋值方式：

// 用 replace 替换当前历史记录 const newUrl = iframe.src.split('#')[0] + '#' + encoded; iframe.contentWindow.location.replace(newUrl);

当然，如果业务允许，还是优先用 postMessage。hash 方案适合的其实是那些“对方页面我们不握代码”的第三方嵌入场景。比如你用某款在线报表工具，它支持通过 URL 参数来初始化报表，那你塞参数进 src 即可，不需要对方适配你的消息协议。

5. 方法四：window.name 传递数据——隐形的数据通道

5.1 window.name 的特殊性质

window.name 在很多年前是一种常用的跨域数据传递方案，现在用得少了，但它的特殊性质在特定场景下依然有用。这个属性的特点在于：窗口对象在页面导航之后，window.name 的值仍然会被保留。也就是说，你在页面 A 里设置了 window.name，然后这个窗口跳转到页面 B，页面 B 依然能读取到这个值。

这意味着，只要 iframe 的 src 从一个跨域地址切换到另一个地址，window.name 作为窗口属性并不会随页面重新加载而清空。于是可以构造一个“中间页”或者说“代理页”：iframe 先加载一个设置好 window.name 的页面，然后通过自身导航到真正的目标页面，目标页面读取 window.name 拿到数据。

这个特性看起来绕，但它在老浏览器环境里，是少有的能在跨域情况下传递非字符串数据的手段。不过需要注意，window.name 只能存字符串，存储量虽然比 hash 大不少（通常能放几 MB），但也有限制，而且它会一直保留到窗口关闭，容易造成内存残留。

5.2 用 window.name 做跨域消息广播的实现

核心思路：父页面创建一个隐藏 iframe，iframe 先加载一个位于目标域的空白页面（这个页面的域名必须和目标域相同），在该页面的 onload 里设置 window.name 为目标数据，然后 iframe 导航到真正的目标页面。目标页面读取 window.name，就能在跨域前提下拿到数据。

这里有一个陷阱：你没法直接通过 iframe 加载一个跨域页面并设置它的 window.name，因为跨域页面里你无法执行脚本。所以必须有一个在目标域下可控的“中转页”，由它来设置 window.name。

<!-- 父页面 --> <iframe id="proxyFrame" style="display:none;"></iframe> <script> const proxyFrame = document.getElementById('proxyFrame'); // 第一步：加载目标域下的代理页 proxyFrame.src = 'https://child.example.com/proxy.html?target=' + encodeURIComponent('https://child.example.com/report.html'); // 代理页加载完成后，它会设置 window.name 并导航到 report.html proxyFrame.onload = function () { // report.html 加载后，我们来读取 window.name // 但注意 onload 会触发多次，需要判断当前 src }; </script>

代理页代码，它需要和目标域名一致，负责设置数据并跳转：

// proxy.html（与目标页同域） // 从 URL 参数里拿到要传的数据和目标地址 const query = new URLSearchParams(window.location.search); const targetUrl = query.get('target'); const payload = JSON.stringify({ token: 'abc123', role: 'admin' }); window.name = payload; window.location.replace(targetUrl);

目标页面读取数据：

// report.html（与 proxy.html 同域） const rawData = window.name; const data = rawData ? JSON.parse(rawData) : null; console.log(data.token); // abc123

这个流程里有个容易被忽略的细节：如果目标页面自身又发生了跳转，window.name 里还带着旧数据，可能被新页面错误读取。所以目标页面在读完数据后，最好立即清空 window.name：

window.name = '';

5.3 为什么 window.name 不该被滥用

window.name 方案在现代浏览器里基本是“能用但没必要”的状态。主要原因有几个：

一是它没有事件机制，父页面和子页面之间无法实时监听变化。你只能等页面加载完成后再去读一次，做不到像 postMessage 那样即时推送。

二是它改的是窗口级别属性，如果同一个窗口里跑了多段业务逻辑，window.name 很容易被覆盖。我在做一个多 iframe 聚合页时试过用 window.name 传状态，结果不同模块之间互相覆盖，排查时非常头疼。

三是它和页面的导航状态深度耦合，一旦用户手动在当前标签页里跳转到别的站点，那些未清空的 window.name 数据就可能被别的页面读到，存在信息泄露风险。所以哪怕是为了兜底，也应该在使用后立刻清理。

对于现代前端项目，我通常的建议是：只有当目标页面我们完全不能改代码、又不支持 postMessage（比如一些古老设备上的内嵌浏览器）时，才考虑 window.name。否则，postMessage 永远是更干净、更安全、更好排查的选择。

6. 方案对比、选型建议与实战排坑

6.1 四种方案横向对比

先放一张对比表，把核心差异列清楚，方便你按场景查。

postMessage 的综合表现最好，尤其在现代浏览器里，它同时解决了安全、实时性和数据结构这三个核心问题。同域直取虽然效率最高，但一旦域名规划变了，维护成本会骤然上升。hash 方案适合做“信号弹”，一句“筛选变了，请刷新”之类的情报传递恰到好处。window.name 则是备胎里的备胎，绝大多数场景不该是首选。

6.2 真实业务场景下的选型建议

结合我接触过的项目，给你几个可以照着用的场景建议。

场景一：Vue3 主应用嵌入报表系统，报表系统独立域名。这种情况跑不了，直接用 postMessage。父页面通过 message 推送筛选条件，子页面通过 message 回传点击事件和报表状态。重点是把消息协议在项目文档里固定下来，比如定义一份window.__REPORT_PROTOCOL__的说明，把 type 的取值、payload 的字段名都列出来，不然半年后接手的人对着代码根本猜不出数据流。

场景二：同一主域名下的存量系统。如果两个系统都挂在同一个域名下，只是不同端口或路径，那 contentWindow 直取效率最高。我在做过一个旧系统改造项目时，老系统没有暴露任何接口，我就用直取方式直接操作它里面的几个输入框和按钮，自动填充表单完成登录。这种操作不能写进正式代码的长期架构里，但做一次性迁移非常管用。

场景三：嵌入第三方图表工具，工具只支持 URL 参数初始化。这种场景就用 URL hash。你只需要把参数拼到 iframe 的 src 后面，第三方页面加载时会自动读取。注意做好 encodeURIComponent 的编解码，避免特殊字符乱码。

场景四：老旧的内部系统，比如还跑在 IE 上的管理后台。IE8、IE9 对 postMessage 的支持比较弱，如果业务方坚持要兼容，window.name 可以作为一个兜底方案。但我得提醒一句：这类环境现在基本已经在淘汰边缘，新项目铁定不推荐为了它去迁就。

6.3 高频问题排查实录

“为什么我调用了 iframe.contentWindow.postMessage，但子页面收不到消息？”

优先级最高的排查项是目标源。检查 postMessage 的第二个参数是不是和目标页面的完整源一致，如果写成了*虽然能发出去，但某些环境下会被目标页面拦截。其次是 iframe 是否已经加载完成。如果你在 iframe 还没 load 时就发消息，内容会被浏览器直接丢进一个待处理的队列，在多数浏览器下不会被真正送达。我的建议是把首条消息放在 iframe.onload 之后再发，而不是写在页面底部脚本里。

“为什么子页面里监听 message，event.origin 显示的是 null？”

这个通常发生在 iframe 的 src 是about:blank或者一个 sandbox 化的 iframe 里。sandbox 属性如果缺少allow-same-origin，iframe 会被当成一个独立的不透明源，在这种情况下，postMessage 的来源就是 null。检查 iframe 标签是不是带了 sandbox 属性，以及有没有完整声明需要的权限。

“iframe 内容导致外层 div 点击事件不触发。”

这个问题和通信本身无关，但很常见。iframe 是一块独立的文档区域，鼠标事件会被子页面文档捕获，不会冒泡到父页面。你在外层 div 上绑定的 click 事件，只要点的是 iframe 区域，父页面是收不到的。解决办法有两种：一种是在 iframe 外覆盖一层透明的遮罩 div，捕获点击后做跳转；另一种是在子页面里监听到点击后通过 postMessage 通知父页面。这就回到了本文的通信主题上，所以本质上还是父子通信问题。

“iframe 隐藏滚动条不生效。”

给 iframe 设置scrolling="no"只是去掉了边框滚动条，但内容超出时子页面内部 window 还是能滚。真正让滚动条消失是按内容尺寸设置 iframe 高度，或者在子页面样式里加overflow: hidden。这两种方法都和跨域通信无关，但既然聊到 iframe 属于常见问题，就一并写进来。如果你在子页面里做完 overflow hidden 后父页面还想调整 iframe 高度，又要把新高度传回父页面，postMessage 又派上用场了。

“为什么设置 iframe 高度后，依旧出现底部白边？”

这是内容自身尺寸的问题。iframe 的父容器高度设了 100%，但子页面 documentElement 的实际高度可能因为 margin 默认值而多出 16px 之类的高度。解决方式是在子页面里先重置 margin 和 padding，再获取document.documentElement.scrollHeight，把它通过 postMessage 传给父页面。这也是我在做嵌入报表时经常用的一条链路。

“为什么有的系统禁止通过 iframe 嵌入自己的页面？”

因为页面通过设置X-Frame-Options响应头或者 CSP 的frame-ancestors指令来限制被嵌入的站点。比如有些商业软件社区版就明确禁止 iframe 嵌入，这种限制不是前端代码能绕过的，你嵌入时会看到一个空白页或者浏览器拦截页。遇到这种页面，再好的通信方案也没有意义，只能找厂商沟通或者走服务端代理方案。

6.4 我的个人实践经验

最后分享一段我在做一个数据大屏项目的体会。当时主页面是 Vue3 写的，需要嵌入一个独立部署的图表模块，两个项目分属不同团队、不同域名。最初我们直接把筛选参数拼在 iframe 的 src 里，子页面加载时读一次，后来发现用户切换筛选条件后子页面无法实时更新，又去补了 postMessage 双向通道。

那一次我最大的收获是：跨域通信的方案选择不是一锤子买卖，它取决于你对双方代码控制力的判断。双方都能改代码，就用 postMessage 这种完善协议；只能改一方，就用 hash 或初始化参数；双方都不能改，那只能接受对方提供的现成机制。

通信方案定了之后，我建议把消息协议、字段格式、有效期都记录在项目的 README 里。iframe 通信不像普通接口调用那样有一份后端 API 文档，消息类型全靠代码注释，时间一长后人根本不知道“{ type: 'FILTER_CHANGED' }”是谁发给谁、发给谁要回什么。踩过这个坑之后，我在新项目里养成了一个习惯：所有跨域通信的 type 字段都集中在同一个常量文件里维护，命名空间加上模块前缀，比如REPORT_、AUTH_、NAV_，一眼就能看出消息属于哪个业务域。

另外一个很实际的小技巧：调试 iframe 通信时，不要只在控制台里看数据，直接在 message 事件回调里打一条带标志的 log，比如console.log('%c[iframe-msg]', 'color:#42b983', event.data)，样式化输出在多个 iframe 同时通信时会帮你快速分清是哪条通道发出的消息。开发环境里打开一个单独的调试页面，把所有来回的消息都记录到一个画面上，比在控制台大海捞针有效率得多。

框架层面的封装，如果项目里多次用到 iframe 通信，我建议抽一个简单的 Emitter 工具类，内部封装 postMessage 的收发和消息序列号关联，让业务代码只关心“我发出去了一个事件”“我收到了一个事件”，而不是到处裸写 event.origin 判断。这层封装做出来后，后面所有页面接入 iframe 通信都能省下至少半天时间。

iframe 跨域通信这件事，本质上就是在浏览器的安全边界和业务需求之间找平衡。四种方法各有优劣，无所谓最好，只在特定场景下最合适。只要你明白每种方案背后的原理，再结合自己的页面控制力去做判断，遇到问题基本都能快速定位到方向。