处理javascript跨域请求主要有三种方法：1. cors是现代主流方案，需服务器设置access-control-allow-origin等响应头，支持复杂请求预检和凭证传递，但需后端配合；2. 代理方案通过前端请求同源后端，再由后端转发请求至目标api，彻底规避浏览器同源策略，适合无法控制第三方服务或需隐藏敏感信息的场景；3. jsonp利用script标签无同源限制的特性实现跨域，仅支持get请求，存在xss风险且错误处理困难，现多用于兼容老旧系统或特定公共api。应优先选择cors或代理方案，综合安全性、兼容性和维护性进行权衡。
在JavaScript中处理跨域请求，核心思路是绕开或利用浏览器同源策略的限制。常见的几种方法包括使用CORS（跨域资源共享）、JSONP，以及设置代理（Proxy）。这些方案各有优劣，选择哪种取决于具体的场景和需求。
解决方案
要搞定JavaScript的跨域请求，我们主要有以下几种途径。每种方法都有其特定的适用场景和考量，理解它们的工作原理能帮助你做出更明智的选择。
CORS（Cross-Origin Resource Sharing）
这是目前最主流、也是最推荐的跨域解决方案。它需要服务器端的配合。简单来说，当浏览器检测到跨域请求时，它会先发送一个“预检请求”（Preflight Request，通常是OPTIONS方法）给服务器，询问服务器是否允许该域的请求。如果服务器在响应头中包含特定的CORS相关字段（如
Access-Control-Allow-Origin），浏览器就会允许后续的实际请求。
JSONP（JSON with Padding）
这是一种利用
<script>标签没有同源策略限制的“漏洞”来实现跨域的方法。你动态创建一个
<script>标签，将其
src指向目标域的API地址，并附带一个回调函数名。服务器接收到请求后，将数据包裹在这个回调函数中返回，浏览器加载脚本后会执行这个函数，从而拿到数据。
代理（Proxy）
这种方式是让前端请求自己的后端服务器，再由后端服务器去请求目标域的API。因为服务器之间没有同源策略的限制，所以后端可以自由地访问任何API。然后后端再把拿到的数据返回给前端。这样，对于前端来说，它始终是在请求同源的后端服务器，完美规避了浏览器的跨域限制。
CORS：现代跨域的基石与实践
说实话，处理跨域这事儿，CORS绝对是现在最“正统”的，也是我们最应该优先考虑的方案。它不是什么取巧的办法，而是W3C制定的一套标准，让浏览器和服务器之间能安全地进行跨域通信。
CORS的核心在于HTTP响应头。当你的前端（比如
http://a.com）想请求另一个域名（
http://b.com/api）的数据时，浏览器会检查这个请求是否跨域。如果是，它会做一些额外的事情。
对于简单的GET或POST请求（没有自定义头部，Content-Type是
application/x-www-form-urlencoded,
multipart/form-data, 或
text/plain），浏览器会直接发送请求，但会在请求头中带上
Origin字段，表明请求来源。
b.com的服务器收到请求后，如果它允许
a.com访问，就会在响应头中加上
Access-Control-Allow-Origin: http://a.com。浏览器看到这个头部，就知道请求合法，然后处理响应。
但对于一些复杂的请求，比如带有自定义头部、使用PUT/DELETE方法，或者
Content-Type是
application/json的请求，浏览器会先发送一个OPTIONS预检请求。这个预检请求就像是浏览器在问服务器：“嘿，我有个跨域请求，来源是
a.com，方法是PUT，还带了个
X-Custom-Header，你允许我这么干吗？”服务器如果允许，会在预检请求的响应中带上
Access-Control-Allow-Methods（允许的方法）、
Access-Control-Allow-Headers（允许的头部）、
Access-Control-Max-Age（预检结果缓存时间）等字段。浏览器收到肯定答复后，才会发送真正的请求。
在使用CORS时，有几个小点需要注意：
-
Access-Control-Allow-Origin
: 这是最重要的，它指定了允许访问的源。你可以指定一个具体的域名，比如http://a.com
，也可以是*
（表示允许所有源，但生产环境慎用，尤其当请求涉及用户凭证时）。 -
Access-Control-Allow-Credentials
: 如果你的请求需要携带Cookie、HTTP认证信息或客户端SSL证书等凭证，前端需要设置withCredentials = true
（比如fetch(url, {credentials: 'include'})），同时服务器必须在响应头中设置Access-Control-Allow-Credentials: true
。*注意：当Access-Control-Allow-Origin
设置为`时，不能同时设置
Access-Control-Allow-Credentials: true`。** 这是一个常见的坑。 -
预检请求的性能: 复杂的CORS请求会多一次OPTIONS请求，这无疑增加了网络开销。
Access-Control-Max-Age
字段可以缓存预检结果，减少后续相同请求的预检次数，优化性能。
前端使用
fetch或
XMLHttpRequest发起请求时，基本不用额外配置什么，浏览器会自动处理CORS逻辑。关键在于后端服务器的配置。
// 前端使用fetch发起一个带凭证的跨域请求
fetch('http://api.example.com/data', {
method: 'GET',
credentials: 'include' // 告诉浏览器发送凭证（如Cookie）
})
.then(response => {
if (!response.ok) {
throw new Error('Network response was not ok');
}
return response.json();
})
.then(data => console.log(data))
.catch(error => console.error('There has been a problem with your fetch operation:', error));
// 后端（Node.js Express示例）
/*
const express = require('express');
const app = express();
app.use((req, res, next) => {
res.header('Access-Control-Allow-Origin', 'http://your-frontend-domain.com'); // 明确指定允许的源
res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization, X-Requested-With');
res.header('Access-Control-Allow-Credentials', 'true'); // 如果需要携带凭证
if (req.method === 'OPTIONS') {
res.sendStatus(200); // 预检请求直接返回200
} else {
next();
}
});
app.get('/api/data', (req, res) => {
res.json({ message: 'Hello from cross-origin API!' });
});
app.listen(3000, () => console.log('Server running on port 3000'));
*/代理（Proxy）方案：绕过浏览器限制的服务器智慧
代理方案，在我看来，是处理跨域问题中最“简单粗暴”但又非常有效的方式。它的核心思想是：既然浏览器有同源策略，那我就不让浏览器直接去访问那个有问题的跨域地址。我让浏览器去访问一个“自己人”的地址，也就是我自己的服务器。然后，由我的服务器去替我访问那个真正的目标API。
为什么这种方式能成功呢？因为同源策略是浏览器为了安全而设置的，它只对浏览器端执行的JavaScript代码有效。而服务器端（比如你的Node.js、Python、Java后端）发起HTTP请求时，是完全没有同源策略限制的。服务器想请求哪个URL就请求哪个URL，想怎么请求就怎么请求。
这种方案的优点显而易见：
- 彻底解决跨域问题：前端代码始终只与自己的后端服务器通信，完全符合同源策略。
- 安全增强：如果你需要访问的第三方API需要API Key或者其他敏感信息，你可以把这些信息放在你的后端，由后端去处理认证，前端完全不需要知道这些敏感信息，提高了安全性。
- 灵活性：后端可以对第三方API的响应进行预处理、缓存，甚至聚合多个API的响应再返回给前端。
当然，它也有一些“代价”：
- 增加了服务器负担：所有的跨域请求都需要经过你的后端服务器中转，这会增加服务器的网络I/O和处理负载。
- 增加了网络延迟：多了一次请求中转，理论上会增加一些网络延迟，但对于大多数应用来说，这点延迟通常可以接受。
- 需要后端支持：你需要一个自己的后端服务器来充当代理。
实际操作中，如果你用的是Node.js，可以使用
http-proxy-middleware这样的库来快速搭建一个代理。如果你用Nginx，配置一个反向代理更是家常便饭。
// 前端请求自己的后端代理地址
fetch('/api/proxy/external-service') // 假设你的后端在同源下监听 /api/proxy/external-service
.then(response => response.json())
.then(data => console.log('Data from external service via proxy:', data))
.catch(error => console.error('Error fetching via proxy:', error));
// 后端（Node.js Express + http-proxy-middleware 示例）
/*
const express = require('express');
const { createProxyMiddleware } = require('http-proxy-middleware');
const app = express();
app.use('/api/proxy', createProxyMiddleware({
target: 'http://external-api.com', // 目标外部API地址
changeOrigin: true, // 改变请求的Origin头部，使其与目标URL的Origin一致
pathRewrite: {
'^/api/proxy': '', // 重写路径，将 /api/proxy 移除
},
onProxyReq: (proxyReq, req, res) => {
// 可以在这里添加自定义头部，比如API Key
// proxyReq.setHeader('X-API-Key', 'YOUR_SECRET_API_KEY');
},
}));
app.listen(3000, () => console.log('Proxy server running on port 3000'));
*/这种方式特别适合那些你无法控制第三方API服务器配置（比如它不支持CORS）的场景，或者你需要隐藏API密钥等敏感信息的情况。
JSONP：老兵的退役与偶尔的闪光
JSONP，这玩意儿在CORS还没普及的时候，简直是前端处理跨域的“救星”。它的原理说起来也挺巧妙的：浏览器对
@@##@@、
<link>、
<script>等标签加载外部资源是没有同源策略限制的。JSONP就是利用了
<script>标签的这个特性。
具体怎么玩呢？前端会动态创建一个
<script>标签，然后把它的
src属性指向你想要请求的跨域API地址。这个地址通常会带一个特殊的查询参数，比如
callback=myCallbackFunction。服务器收到请求后，不会直接返回JSON数据，而是把JSON数据包裹在一个函数调用里，这个函数名就是你传过去的
myCallbackFunction。
举个例子，如果你的请求是
http://api.example.com/data?callback=handleData，服务器可能返回：
handleData({"name": "Alice", "age": 30});当浏览器加载这个脚本后，它会立即执行这段JavaScript代码，也就是调用了你预先定义好的
handleData函数，并将数据作为参数传进去。这样，你就能在
handleData函数里拿到跨域的数据了。
JSONP的优点在于：
-
兼容性好：因为它利用的是
<script>
标签的特性，所以几乎所有的老旧浏览器都支持。 - 简单易实现：对于一些简单的GET请求，实现起来确实不复杂。
但是，JSONP的缺点也相当明显，这也是为什么它现在逐渐被CORS取代，成为了一个“老兵”：
- 只支持GET请求：你不能用JSONP发送POST、PUT、DELETE等请求。因为它本质上是加载一个脚本，只能通过URL参数传递数据。
- 安全性问题：由于是直接执行服务器返回的脚本，如果服务器返回的内容被恶意篡改，或者服务器本身存在漏洞，那么你的页面就可能面临XSS（跨站脚本攻击）的风险。你需要完全信任提供JSONP服务的第三方。
- 错误处理不友好：你很难像处理普通XHR请求那样，捕获到JSONP请求的错误状态码（比如404、500）。你只能通过回调函数是否被调用来判断请求是否成功。
现在，除非你是在维护一个非常老旧的项目，或者需要与某个只支持JSONP的公共API（比如一些天气预报、汇率查询API）交互，否则我真的不建议你优先考虑JSONP。CORS和代理方案在安全性、功能性和可维护性上都远超JSONP。
// 前端使用JSONP的简单实现
function handleUserData(data) {
console.log('Data from JSONP:', data);
// 在这里处理从服务器获取到的数据
}
// 动态创建script标签并插入到页面
const script = document.createElement('script');
script.src = 'http://api.example.com/users?callback=handleUserData'; // 假设API支持JSONP，并接受callback参数
document.body.appendChild(script);
// 注意：这里没有错误处理机制，如果请求失败，handleUserData不会被调用
// 你可能需要设置一个超时机制来判断请求是否成功总结一下，JavaScript处理跨域请求，CORS是首选，它是一种标准且安全的方案。代理是万能药，尤其适合无法控制第三方服务器或需要更高安全性的场景。而JSONP，虽然曾经辉煌，但现在更多是作为一种历史遗留或特定场景下的备选方案。选择哪种，最终还是看你的具体需求和对安全、性能的权衡。
