iframe 通信不畅？可能是这些原因导致的

iframe 作为一种常用的嵌入网页的方法，给我们开发者带来了很多便利，但同时也伴随着一些挑战，尤其是跨域通信的问题。在这篇文章中将探讨笔者遇到的一些无法通信的原因及其解决方法：

原因

父页面在 postMessage 的时候没有指定域：

根据 MDN 上的描述来看，otherWindow.postMessage(message, targetOrigin, [transfer]) 中的第二个参数 targetOrigin 的意义是指定哪些窗口能接收到消息事件，其值可以是字符串 *（表示无限制）或者一个 URI。在发送消息的时候，如果目标窗口的协议、主机地址或端口这三者的任意一项不匹配 targetOrigin 提供的值，那么消息就不会被发送；只有三者完全匹配，消息才会被发送。

通常我们并不会去传入第二个参数，因此在父页面和 iframe 不同源的情况下，无法通信。

js 复制代码

iframe.contentWindow?.postMessage({ type: 'data', data }, "*")

iframe未就绪

如果你的主页面在 iframe 的内容完全加载之前就发送了消息，那么 iframe 可能会错过消息。你需要确保 iframe 已经完全加载后再发送消息。

js 复制代码

iframe.onload = () => {
  iframe.contentWindow?.postMessage({ type: 'data', data }, "*")
}

除此之外，这里还遇到了一个问题：在实际业务中，父页面按照上述代码发送数据，iframe 中则在 useEffect 中去监听 message 事件。结果发现父页面发送数据后了，message 事件还没设置上。浅浅推测下应该是 useEffect 的执行时机是在 dom 渲染结束之后的缘故。

我们可以采用主动获取 数据的方式。即 iframe 中也通过 window.parent.postMessage 告知父页面自己已经加载完毕了，父页面接收到这个信息后，再 postMessage 将数据传给 iframe。

协议不一致

在 Chrome 浏览器中，当你使用 https 页面去加载一个 http 的 iframe 的时候，会产生这样的报错：

这是浏览器自带的保护机制：

If your website delivers HTTPS pages, all active mixed content delivered via HTTP on these pages will be blocked by default. Consequently, your website may appear broken to users (if iframes or plugins don't load, etc.).

但是我们又没法去升级为 https 或者是懒得去起代理服务。其实 Chrome 浏览器中提供了规避方法，只需要打开 chrome://flags/，进入 Chorme Experiments 设置页面，搜索 Insecure origins treated as secure，在里面输入我们想规避的url，再点击 Enable 启用功能即可。

本文介绍了 3 种导致 iframe 无法通信的常见原因并提出了有效的解决方案，相信各位读者遇到同样问题时，已经有了大概的解决办法。如果你有任何疑问或想法，欢迎在下方留言，我们一起探讨。感谢你的阅读，让我们期待下次相聚。