前端跨越方式有哪些

发现宝藏

前些天发现了一个巨牛的人工智能学习网站，通俗易懂，风趣幽默，忍不住分享一下给大家。【宝藏入口】。

前端跨域（Cross-Origin Resource Sharing，CORS）是指在不同源（protocol、domain、port）之间进行数据交互的过程。由于浏览器的同源策略（Same-Origin Policy）限制，前端 JavaScript 脚本只能访问同一源的资源，而无法直接访问不同源的资源。为了实现不同源之间的资源共享，常用的跨域解决方案有以下几种：

1. CORS（Cross-Origin Resource Sharing）

CORS 是最常用的一种跨域方式，它通过服务器端的 HTTP 响应头来告知浏览器允许跨域请求。具体做法是，服务器通过设置相应的 HTTP 头部，明确哪些来源可以访问其资源。

主要的 CORS 相关 HTTP 响应头：
- Access-Control-Allow-Origin：指定允许跨域的来源，值可以是具体的域名（如 https://example.com）或者 *（表示允许所有域访问）。
- Access-Control-Allow-Methods：指定允许的 HTTP 方法（如 GET、POST、PUT、DELETE 等）。
- Access-Control-Allow-Headers：指定允许的请求头。
- Access-Control-Allow-Credentials：是否允许发送 Cookie 和 HTTP 认证信息（值为 true 或 false）。
- Access-Control-Max-Age：指定预检请求（preflight request）缓存的时间。
使用场景：
- 当前端请求服务器的资源时，后端必须在响应头中配置 CORS 相关的头部，浏览器才会允许跨域请求。

例子：

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type
Access-Control-Allow-Credentials: true

2. JSONP（JSON with Padding）

JSONP 是一种较早的跨域解决方案，通过动态插入 <script> 标签来跨域请求数据。<script> 标签没有跨域限制，因此可以从不同源加载 JavaScript 文件。JSONP 通过回调函数来传递数据。

原理：
- 前端在请求中传递一个回调函数名，服务器返回一个包含回调函数调用的 JavaScript 脚本，脚本执行时会调用回调函数并传递数据。
使用场景：
- 适用于只需要 GET 请求的场景，且通常只获取数据，不需要修改服务器数据。
- 由于 JSONP 是通过 <script> 标签来实现的，因此只能进行 GET 请求。

例子：

// 前端请求
<script src="https://api.example.com/data?callback=myCallback"></script>// 服务器返回
myCallback({ name: 'John', age: 30 });

缺点：
- 只能支持 GET 请求。
- 存在一定的安全风险，因为服务器返回的内容是 JavaScript 代码，可能被利用进行恶意操作。

3. WebSocket

WebSocket 是一种基于 TCP 的协议，用于建立持久的双向通信连接，它是跨域的，并且不受同源策略的限制。WebSocket 可以在客户端和服务器之间进行实时、双向的数据交换，常用于实时应用（如即时消息、在线游戏等）。

原理：
- 客户端通过 WebSocket 连接到服务器（使用 ws:// 或 wss:// 协议），建立起一个持久的连接，之后可以实时地发送和接收数据。
使用场景：
- 用于需要高频次、低延迟通信的应用，如在线聊天、实时通知、股票行情、实时数据流等。
优点：
- 不受同源策略的限制。
- 实时通信，低延迟，双向数据传输。
缺点：
- 需要 WebSocket 服务器的支持。
- 相较于传统 HTTP 请求，WebSocket 的使用和配置较为复杂。

4. PostMessage

PostMessage 是 HTML5 提供的跨域消息传递机制，允许不同源的窗口（如 iframe、弹出窗口、父窗口）之间传递消息。

原理：
- 使用 window.postMessage() 方法在不同的窗口或 iframe 中发送消息。目标窗口可以通过监听 message 事件来接收消息。
使用场景：
- 在父子窗口、嵌套 iframe、不同标签页或不同域之间传递消息时。
- 适用于跨域通信，但不涉及数据传输的详细内容。

例子：

// 父窗口发送消息
iframe.contentWindow.postMessage('Hello from parent', 'https://child-domain.com');// 子窗口接收消息
window.addEventListener('message', (event) => {if (event.origin === 'https://parent-domain.com') {console.log('Message received:', event.data);}
});

优点：
- 可以跨越窗口、跨域、跨文档。
- 安全性较好，接收方需要验证消息来源。
缺点：
- 只能传递字符串或对象。
- 需要手动管理消息传递的安全性（如验证消息来源）。

5. Iframe + Server-Side Proxy

使用 iframe + 后端代理 是一种传统的跨域解决方案，通常通过将请求发送到自己的服务器，再由服务器代为请求其他域的资源，避免了浏览器的跨域限制。

原理：
- 前端请求自己的服务器，服务器代替前端向其他域发起请求，获取数据后返回给前端。通过这种方式，前端不直接与跨域资源交互，从而绕过了浏览器的跨域限制。
使用场景：
- 适用于前端无法直接跨域访问第三方 API 的情况，通过服务器代理来解决跨域问题。
优点：
- 可以跨越多个域，解决跨域问题。
- 可隐藏真实的跨域 API，增强安全性。
缺点：
- 需要配置和维护后端代理服务。
- 增加了服务器的负担，可能带来性能问题。

6. Proxy（代理）

代理是前端解决跨域的另一种方式，通常指通过配置开发服务器代理（如使用 webpack-dev-server、vite 等）来将请求代理到目标服务器。这通常只在开发环境下使用。

原理：
- 前端请求通过开发服务器代理转发到目标服务器，代理服务器向目标服务器发起请求，返回响应给前端。浏览器不会认为这是跨域请求。
使用场景：
- 适用于开发环境中的跨域请求，通常用于开发阶段调试时解决跨域问题。
优点：
- 配置简单，只需要在开发环境中设置代理即可。
缺点：
- 仅适用于开发环境，在生产环境中无法使用。

总结

常见的前端跨域解决方案包括：

CORS：最常用且标准的跨域解决方案，需后端支持。
JSONP：适用于 GET 请求，早期常用的跨域方式，但存在安全隐患。
WebSocket：支持双向通信的跨域方式，适合实时应用。
PostMessage：用于跨域的窗口间通信，适合嵌套 iframe 或父子窗口通信。
Iframe + 后端代理：通过服务器代理跨域请求，适用于不支持 CORS 的服务器。
代理：前端开发中常用的解决跨域的手段，适用于开发环境。

选择哪种方式取决于具体的应用场景、后端支持情况和跨域请求的类型。