如何用BOM实现页面的跨域通信？

实现bom层面的跨域通信核心机制是window.postmessage方法。其解决方案包括：1. 发送端通过iframe元素的contentwindow属性获取子窗口对象并调用postmessage，指定目标源以确保安全；2. 接收端监听message事件，验证event.origin后处理数据并可进行回复；3. 安全性方面必须严格检查发送方源和接收方目标源，避免使用通配符'*'；4. 老旧方法如url哈希、window.name因效率低、安全性差已被淘汰；5. 实际开发中需注意时序问题、数据序列化一致性，并利用console.log、断点调试等技巧排查问题。

要在浏览器对象模型（BOM）层面实现页面的跨域通信，核心机制是利用window.postMessage方法。这基本上是现代浏览器中最安全、最可靠的跨域通信手段，它允许不同源的窗口（包括iframe、弹出窗口等）之间安全地交换数据。

解决方案

window.postMessage方法提供了一种受控的方式来规避同源策略，使得不同源的文档能够发送和接收消息。其工作原理可以简单分为发送端和接收端。

发送端（例如，父页面向iframe发送消息）：

父页面可以通过其iframe元素的contentWindow属性来获取子页面的window对象，然后调用postMessage。

// 父页面 (parent.html)
const iframe = document.getElementById('myIframe');
const targetOrigin = 'http://child.example.com'; // 必须指定目标源，或者使用 '*' (不推荐用于生产环境)

// 确保iframe加载完毕再发送，或者在iframe加载事件中发送
iframe.onload = () => {
    iframe.contentWindow.postMessage('你好，iframe！这是一条来自父页面的消息。', targetOrigin);
    console.log('消息已发送到iframe。');
};

// 也可以直接在某个事件中发送
// document.getElementById('sendMessageBtn').addEventListener('click', () => {
//     iframe.contentWindow.postMessage({ type: 'data', payload: '复杂数据对象' }, targetOrigin);
// });

postMessage的第一个参数是你要发送的数据，可以是字符串、数字、布尔值、数组、对象，甚至是File对象或Blob对象等。第二个参数targetOrigin至关重要，它指定了接收消息的窗口的源。如果你不确定或想发送给任何源，可以使用'*'，但这会带来安全风险，因为任何页面都可以接收到你的消息。我个人建议，除非你明确知道风险并接受，否则请务必指定具体的源。

接收端（例如，iframe接收父页面发送的消息）：

接收消息的页面需要添加一个事件监听器来监听message事件。

// 子页面 (child.html，位于 http://child.example.com)
window.addEventListener('message', (event) => {
    // 关键的安全检查：验证消息来源的源
    if (event.origin !== 'http://parent.example.com') { // 必须验证！
        console.warn('收到来自未知源的消息，已忽略。', event.origin);
        return;
    }

    console.log('收到消息：', event.data);
    console.log('消息来源：', event.origin);
    console.log('发送者窗口对象：', event.source); // 引用发送消息的窗口对象

    // 接收到消息后，也可以回复
    event.source.postMessage('收到你的消息了，父页面！', event.origin);
});

console.log('子页面已准备好接收消息。');

这里，event对象包含了几个有用的属性：

• event.data: 接收到的数据。
• event.origin: 发送消息的文档的源（协议、域名、端口）。这是进行安全验证的关键。
• event.source: 对发送消息的窗口或iframe的引用。你可以用它来回复消息。

postMessage的安全性：不得不提的那些事儿

在使用window.postMessage进行跨域通信时，安全性是首要考虑的问题，甚至可以说，它比通信本身更重要。我个人觉得，很多开发者在追求功能实现的时候，往往容易忽略这一点，但一旦出了问题，那可不是闹着玩儿的。

首先，发送方指定targetOrigin是避免消息被不当接收的关键。如果你把targetOrigin设为'*'，那意味着你的消息可能会被任何一个监听message事件的页面接收到。想象一下，你把一个包含敏感信息的消息发出去，结果被一个恶意网站的iframe给截获了，这简直就是灾难。所以，始终明确指定目标源，比如'https://your-trusted-domain.com'，这是最基本的安全实践。

其次，也是同样重要的，接收方必须严格验证event.origin。即使发送方指定了目标源，也不能保证接收方收到的消息就一定是来自预期的源。恶意网站完全可以伪造一个postMessage事件，并尝试发送数据到你的页面。如果你的接收端没有验证event.origin，就直接处理event.data，那么你的页面就可能面临跨站脚本（XSS）攻击的风险。举个例子，如果接收到的数据被直接插入到DOM中，或者被当作JavaScript代码执行，那攻击者就能在你的页面上为所欲为。所以，每次收到消息，第一件事就是if (event.origin !== '预期的源') { return; }，这是铁律，没有商量的余地。

最后，关于数据本身，虽然postMessage支持发送复杂的数据结构，但在处理接收到的数据时，仍然要像处理任何外部输入一样，进行输入验证和净化。不要盲目相信event.data的内容，特别是当它可能被用来构建HTML或执行脚本时。

除了postMessage，还有哪些BOM跨域通信方式？为什么它们被淘汰了？

说实话，在postMessage出现之前，前端开发者为了实现跨域通信，真是绞尽脑汁，想出了不少“奇技淫巧”。这些方法虽然在特定场景下能解决问题，但大多存在明显的局限性或安全隐患，所以现在基本上都已经被postMessage取代了。

一个比较经典的例子是利用URL的哈希值（window.location.hash）。这种方法的思路是，父页面和子页面（通常是iframe）通过不断改变URL的哈希值来传递信息。比如，父页面通过修改iframe的src来设置哈希值，子页面通过监听hashchange事件来获取哈希值。反之亦然，子页面也可以通过修改自身的哈希值，然后让父页面通过一个中间iframe（同源）来读取。这种方式的缺点非常明显：数据量小，只能是字符串；需要轮询或者频繁修改URL导致历史记录混乱；而且安全性很差，哈希值是公开的，容易被劫持。

另一个是利用window.name属性。window.name在页面跳转后仍然保持不变，并且可以存储相当大的字符串（通常是几MB）。利用这个特性，一个页面可以在iframe中加载一个不同源的页面，然后让这个iframe跳转到一个与父页面同源的空白页。由于window.name的值在跳转后依然存在，父页面就可以安全地读取iframe的window.name来获取之前跨域页面设置的数据。这种方法虽然能传输较大数据，但操作流程非常复杂，需要两次页面跳转，效率低下，而且只能单向通信，每次通信都需要重新加载iframe，这在实际应用中简直是噩梦。

在我看来，这些老旧的方法都像是“打补丁”，为了绕过同源策略而生，但都带着各自的“病根”。postMessage的出现，就像是给跨域通信提供了一个官方且健壮的API，它直接在浏览器层面解决了安全性和通信效率的问题，所以，现在几乎所有的跨域通信场景，我们都会优先考虑postMessage。

实现postMessage时可能遇到的坑和调试技巧

即便postMessage是如此强大和现代，但在实际开发中，你还是可能会踩到一些坑，或者在调试时感到困惑。这玩意儿有时候就是这样，理论上很清晰，实践起来却有各种小脾气。

最常见的坑：时序问题

你可能会发现，有时发送的消息接收不到。这往往是时序问题。比如，你尝试向一个尚未完全加载的iframe发送消息。postMessage是异步的，但如果目标window对象还没准备好，消息自然就发不出去。解决方法通常是在iframe加载完成后（iframe.onload事件）再发送消息，或者在接收端准备好之后（例如，接收端发送一个“我已准备好”的消息给发送端）再开始通信。

数据序列化和反序列化

虽然postMessage支持发送复杂对象，因为它内部使用了结构化克隆算法。但有时候，为了更好的兼容性或者在一些特殊场景下，你可能会习惯性地对发送的数据进行JSON.stringify()，然后在接收端JSON.parse()。这本身不是问题，但要确保两边都保持一致。如果你发送了一个原生对象，而接收端却尝试JSON.parse()一个非JSON字符串，那肯定会报错。

调试的痛点

postMessage的调试确实有点儿玄乎，因为消息是在不同的window上下文之间传递的，不像HTTP请求那样能在网络面板里一目了然。

• Console.log大法： 这是最直接有效的。在发送方和接收方的JavaScript代码中，大量使用console.log来打印发送前的数据、接收到的数据、event.origin等关键信息。通过观察控制台的输出，你可以判断消息是否发出、是否收到、以及收到的内容是否正确。
• 断点调试： 在发送和接收postMessage的代码行设置断点。在Chrome DevTools中，你可以选择不同的执行上下文（比如父页面的top和iframe的iframe-name），分别在各自的上下文中进行断点调试，观察变量的值和代码的执行流程。
• 模拟和简化： 如果通信复杂，可以先写一个最简单的发送和接收例子，确保基础功能正常。然后逐步添加复杂性。有时候，问题可能不是出在postMessage本身，而是你处理消息的逻辑，或者目标window对象获取不正确。

总之，postMessage是现代Web开发中不可或缺的跨域通信利器，掌握它的安全机制和一些调试技巧，能让你在处理复杂的前端交互时更加游刃有余。

以上就是如何用BOM实现页面的跨域通信？的详细内容，更多请关注php中文网其它相关文章！