跨页面通讯
背景
假如用户打开了两个浏览器标签页,这两个标签页可能同源,也可能不同源,但是当用户在其中一个页面进行某些操作时,需要“通知”到另一个页面,也就是实现所谓的跨页面通讯,这在一些场景下非常重要。
首先我们来看一下什么是同源,源,也就是指协议+域名+端口号,如果这三者都相同,注意是都相同,那么就认为他们是同源的。浏览器出于安全考虑,会执行非常严格的“同源策略”,即非同源的页面不可能进行通讯,当然这也不是绝对的,在某些情况下可以绕过同源策略。
由于同源策略的影响,一些跨页面方案无法在非同源的页面中使用,例如storage、cookie等,而这时候可以采用postMessage等替代方案。
实现方案
postMessage
postMessage是官方推荐的跨域方案,通过postMessage不仅可以实现跨页面通讯,而且它还不受同源策略的影响,这意味着它可以向非同源的页面进行通讯。
// 发送消息 function sendMessage() { const message = { name: "张三" }; const otherWindow = window.open(url) otherWindow.postMessage(message, "*"); } // 接收消息 window.onmessasge = function onMessage(event) { const message = event.data; console.log(message); }
注意最好在onMessage事件中验证一下发送源。
这种方式的优点:
- 安全性高
- 可以跨域
- 支持复杂的数据
缺点也很明显,一定需要另一个页面的window对象,可以通过
window.parent
或者window.open
这些方法拿到,但是如果不能拿到另一个页面的window对象,那么这种方法就不可用。cookies
第二种方式是通过cookie来实现跨页面通讯,这是因为cookie在同源页面中是被“共享”的,因此你可以通过设置cookie来进行跨页面通讯,但是注意这要求是同源的。
// 发送消息 function sendMessage() { const message = { name: "张三", }; document.cookie = "message=" + JSON.stringify(message); } // 接收消息 function onMessage() { const message = JSON.parse(document.cookie.split("=")[1]); console.log(message); }
优点有
- 实现简单
- 兼容性强,毕竟几乎所有主流浏览器都支持cookie
缺点也很多
- 实时性差,比较难监听对方什么时候设置了cookie
- 只支持简单的数据
- 不支持跨域
- 浏览器对cookie大小有限制,不能存放太多数据
- 安全性差,有泄漏和被篡改的风险
- 影响性能,cookie在某些情况下会被http请求携带,如果设置太多无关的cookie可能会影响网络传输
总而言之,不建议使用这种方式。
storage
另一种方式是通过storage来实现跨页面通讯,这种方式类似于上一种使用cookie的方案,但是相比较而言优点更多。首先可以通过监听
window.onstorage
事件来确定对方什么时候发送了通知,其次storage可以存储的数据大约有5-10mb左右,比cookie多得多。// 发送消息 function sendMessage() { const message = { name: "张三", }; localStorage.setItem("message", JSON.stringify(message)); } // 接受消息 window.onstorage = function(e){ // ... }
优点
- 实现简单
- 实时性更好一些
- 相较于cookie,可以存储更多数据
缺点
- 安全性较差
- 不支持跨域
webSocket
webSocket是一种全双工协议,这种方法其实已经不是单纯靠前端技术实现了,通过webSocket实现的跨页面通讯需要借助后端来实现,本质上就是两个页面都通过websocket协议与服务器相连,然后一个页面发送消息到服务器,然后将这则消息通知给另一个页面。这里就不展开讲websocket了,有兴趣的话可以参考MDN。
优点是:
- 实时性强
- 支持复杂的数据
- 支持跨域
缺点
- 需要后端参与
- 实现复杂
BroadcastChannel
// 发送消息 const channel = new BroadcastChannel("my-channel"); channel.postMessage("Hello, world!"); // 接收消息 channel.onmessage = function (event) { console.log(event.data); // "Hello, world!" };
优点
- 无需感知另一个页面(postMessage需要拿到另一个页面的window对象才能通讯)
- 简单易用,只需要几行代码即可。
- 安全,BroadcastChannel 使用 EventSource 对象来实现通信,相较于cookie和storage这几种方案安全性更好
缺点
- 不支持跨域,只支持同源页面
- 兼容性差
总结
跨页面通讯是前端开发中常见的需求。根据同源策略,同源的页面之间可以直接进行通信,而非同源的页面之间需要使用绕过同源策略的方法才能进行通信。
本文介绍了几种常用的跨页面通讯方案,包括:
- postMessage:官方推荐的跨域方案,支持跨域、复杂数据,但需要另一个页面的 window 对象。
- cookies:同源方案,实现简单、兼容性强,但实时性差、不支持跨域、安全性差。
- storage:同源方案,实现简单、支持 onstorage 事件,但安全性较差、不支持跨域。
- WebSocket:全双工协议,支持实时性、复杂数据、跨域,但需要后端参与、实现复杂。
- BroadcastChannel:同源方案,无需感知另一个页面、简单易用、安全,但不支持跨域。
在选择跨页面通讯方案时,应根据实际需求进行选择。如果需要跨域通信、支持复杂数据、实时性强,则可以选择 WebSocket 或 BroadcastChannel。如果只需要同源通信,则可以选择 cookies、storage 或 BroadcastChannel。