浏览器同源策略就像一道隐形的围墙，把不同域的资源隔离开来，让前端开发人员在处理跨域请求时头疼不已。但别担心，这里我们不玩虚的，直接上干货。下面这8种方案，每一种都经过实战检验，帮你轻松应对跨域难题。
什么是跨域？同源策略的真相
同源策略(Same Origin Policy)是浏览器最核心的安全机制，由Netscape公司在1995年引入。所谓同源，是指”协议+域名+端口”三者完全一致。当这三个要素中任意一个不同时，就构成了跨域请求。
同源策略限制了三大行为：
- 无法读取其他域的cookie、localStorage和IndexedDB
- 无法操作其他域的DOM
- 无法通过Ajax发送跨域请求
简单来说，浏览器就像一个严格的保安，只允许同一家的员工进出，其他公司的人都得在门外等。这虽然保护了用户安全，却给前端开发带来了不少麻烦。
JSONP：老将出马，虽老犹荣
JSONP（JSON with Padding）利用了<script>标签不受同源策略限制的特性。它的原理很简单：前端动态创建一个<script>标签，指定src为跨域接口，后端将数据包裹在回调函数中返回。
// 前端代码
function handleResponse(data) {
console.log('收到数据:', data);
}
const script = document.createElement('script');
script.src = 'http://api.example.com/data?callback=handleResponse';
document.body.appendChild(script);
优点：兼容性极好，老浏览器也能用；实现简单，不需要后端额外配置。
缺点：只能用GET方法；没有错误处理机制；存在XSS安全风险。就像用老式电话打跨域电话，虽然能打通，但安全性和灵活性都大打折扣。
CORS：现代浏览器的首选方案
CORS（Cross-Origin Resource Sharing）是W3C标准，通过设置响应头来告诉浏览器是否允许跨域请求。这是目前最推荐的解决方案。
关键响应头：
Access-Control-Allow-Origin：指定允许的源，可以是*或具体域名Access-Control-Allow-Methods：允许的HTTP方法Access-Control-Allow-Headers：允许的请求头Access-Control-Allow-Credentials：是否允许发送Cookie
简单请求：GET、POST、HEAD请求，且请求头为Accept、Accept-Language等。
非简单请求：会先发送OPTIONS预检请求，验证服务器是否允许。
优点：支持所有HTTP方法；安全性比JSONP高；错误处理更完善。
缺点：需要后端配合设置响应头；部分旧浏览器（IE8-9）支持不佳。
代理服务器：绕过同源策略的”中间人”
在开发环境中，可以使用代理服务器来转发请求。前端请求本地代理，代理再转发到目标服务器。
实现方式：
// 使用Webpack Dev Server配置
devServer: {
proxy: {
'/api': {
target: 'http://api.example.com',
changeOrigin: true,
pathRewrite: { '^/api': '' }
}
}
}
优点：对前端透明；避免了跨域问题；开发环境配置简单。
缺点：生产环境需要额外部署代理；可能增加网络延迟；后端需要额外处理代理请求。
Nginx反向代理：生产环境的扛把子
在生产环境中，Nginx反向代理是最常见的解决方案。通过配置Nginx将跨域请求转发到目标服务器。
Nginx配置示例：
location /api/ {
proxy_pass http://api.example.com/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
add_header 'Access-Control-Allow-Origin' '*';
}
优点：高性能；配置灵活；适合生产环境。
缺点：需要运维人员介入；配置不当可能引发安全问题。
WebSocket：全双工通信的”秘密通道”
WebSocket是一种全双工通信协议，基于TCP连接，不受同源策略限制。
使用示例：
const socket = new WebSocket('ws://api.example.com/socket');
socket.onmessage = function(event) {
console.log('收到消息:', event.data);
};
socket.send('Hello WebSocket');
优点：支持双向通信；不受同源策略限制；适合实时应用。
缺点：需要服务器支持WebSocket；配置相对复杂；不是所有场景都适用。
iframe + postMessage：页面间的”秘密通信”
通过iframe嵌入跨域页面，使用postMessage进行跨域通信。
父页面：
const iframe = document.getElementById('my-iframe');
iframe.contentWindow.postMessage('Hello from parent', 'http://example.com');
window.addEventListener('message', function(e) {
if (e.origin === 'http://example.com') {
console.log('收到子页面消息:', e.data);
}
});
子页面：
window.addEventListener('message', function(e) {
if (e.origin === 'http://parent-domain.com') {
console.log('收到父页面消息:', e.data);
e.source.postMessage('Hello from child', e.origin);
}
});
优点：无需后端支持；适用于页面间通信。
缺点：只能用于页面间通信；需要双方配合；安全性需谨慎处理。
document.domain + iframe：同源页面的”秘密通道”
当两个页面属于同一主域（如a.example.com和b.example.com）时，可以通过设置document.domain来实现跨域通信。
父页面：
document.domain = 'example.com';
const iframe = document.createElement('iframe');
iframe.src = 'http://b.example.com/child.html';
document.body.appendChild(iframe);
子页面：
document.domain = 'example.com';
// 可以访问父页面的DOM
console.log(window.parent.document);
优点：适用于同一主域下的子域通信；无需后端支持。
缺点：只能用于同一主域下的子域；需要双方都设置document.domain。
总结：如何选择适合的跨域方案
面对这么多跨域解决方案，如何选择？这里有个简单决策树：
- 如果是GET请求且对安全性要求不高，可以考虑JSONP（但要小心XSS风险）。
- 如果是现代浏览器且可以与后端配合，CORS是最佳选择。
- 开发环境可以使用代理服务器，简单方便。
- 生产环境推荐Nginx反向代理，性能和安全性都有保障。
- 实时通信场景，WebSocket是不二之选。
- 页面间通信，iframe + postMessage是可靠方案。
记住，跨域不是问题，而是解决问题的起点。每种方案都有其适用场景，没有绝对的”最好”，只有”最合适”。选择时要综合考虑安全性、开发复杂度、浏览器兼容性等因素。
