深度解析跨域问题：真实场景、解决方案与进阶方案

跨域，是每个前端开发者都绕不开的"拦路虎"。本文将从实际开发场景出发，详细剖析跨域问题的成因、解决思路以及多种备选方案，并用流程图帮你理清请求流程。

一、什么是跨域？为什么会出现？

跨域（Cross-Origin）指的是浏览器同源策略 （Same-Origin Policy）的限制。同源策略要求：协议、域名、端口号 三者完全一致，才能共享资源。只要有一项不同，浏览器就会阻止 XMLHttpRequest、Fetch 等请求的响应结果。

同源策略是浏览器安全的基石，但它也间接"误伤"了正常的跨域通信需求。

常见跨域场景举例

当前页面地址	请求地址	是否跨域	原因
`http://www.a.com`	`http://www.a.com/api`	否	同源
`http://www.a.com`	`https://www.a.com/api`	是	协议不同（http vs https）
`http://www.a.com`	`http://www.b.com/api`	是	域名不同
`http://www.a.com:8080`	`http://www.a.com:80/api`	是	端口不同

二、真实场景 ------ 我在项目中遇到的跨域问题

场景一：前后端分离开发环境

背景：前端使用 Vue + webpack-dev-server 启动在 http://localhost:8080，后端 Spring Boot 启动在 http://localhost:8081。前端调用登录接口时，浏览器报错：

复制代码

Access to XMLHttpRequest at 'http://localhost:8081/login' from origin 'http://localhost:8080' has been blocked by CORS policy

分析：端口号不一致（8080 vs 8081），触发了跨域。这是开发环境中最常见的场景。

场景二：微服务架构中的前端调用

背景：前端页面部署在 https://gw.xxx.com，需要分别调用订单服务（order.svc.com）和用户服务（user.svc.com）。由于域名不同，所有接口都被跨域策略拦截。

场景三：第三方开放 API 调用

背景：一个天气查询页面，前端直接通过 axios 请求 http://api.weather.com/data，浏览器报跨域错误。因为第三方 API 没有返回 Access-Control-Allow-Origin 响应头。

三、解决方案 ------ 从根源到实战

方案一：CORS（跨域资源共享）★★★★★

原理：服务器通过添加特定的响应头，明确告诉浏览器"允许某个源访问"。这是目前最标准、最彻底的解决方案，支持所有 HTTP 方法（GET、POST、PUT、DELETE 等）。

实现：在后端代码中配置 CORS 过滤器或中间件。

Spring Boot 示例（全局配置）

java 复制代码

@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")          // 允许所有接口
                .allowedOrigins("http://localhost:8080") // 允许的前端源
                .allowedMethods("GET", "POST", "PUT", "DELETE")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

Node.js (Express) 示例

javascript 复制代码

app.use((req, res, next) => {
    res.header('Access-Control-Allow-Origin', 'http://localhost:8080');
    res.header('Access-Control-Allow-Methods', 'GET,POST,PUT,DELETE');
    res.header('Access-Control-Allow-Headers', 'Content-Type');
    next();
});

Nginx 反向代理中配置 CORS

nginx 复制代码

location /api/ {
    add_header Access-Control-Allow-Origin $http_origin;
    add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS';
    add_header Access-Control-Allow-Headers 'DNT,Keep-Alive,Content-Type';
    if ($request_method = 'OPTIONS') {
        return 204;
    }
}

方案二：代理服务器（devServer / Nginx）★★★★☆

原理：同源策略只针对浏览器，服务器之间没有跨域限制。将前端请求先发送到与前端同源的代理服务，由代理转发到真正的后端，再把响应返回给浏览器。

适用场景：开发环境快速解决、不想修改后端代码、或者需要对多个后端进行聚合。

Vue CLI 中配置 devServer 代理

javascript 复制代码

// vue.config.js
module.exports = {
  devServer: {
    proxy: {
      '/api': {
        target: 'http://localhost:8081',  // 后端地址
        changeOrigin: true,                // 修改请求头中的host
        pathRewrite: { '^/api': '' }       // 重写路径
      }
    }
  }
}

Nginx 反向代理配置

nginx 复制代码

server {
    listen 80;
    server_name myapp.com;
    
    location /api/ {
        proxy_pass http://backend-service:8081/;
        proxy_set_header Host $host;
    }
}

方案三：JSONP（仅限 GET 请求）★★☆☆☆

原理：利用 <script> 标签不受同源策略限制的特性，通过动态创建 script 标签，将回调函数名作为参数传给服务器，服务器返回一段调用该回调函数的 JavaScript 代码。

局限性 ：只能支持 GET 请求，不能处理 POST、PUT 等，且需要服务器配合返回 callback(data) 格式。目前基本被 CORS 取代。

实现示例：

javascript 复制代码

// 前端
function jsonp(url, callback) {
    const script = document.createElement('script');
    const callbackName = 'jsonp_cb_' + Date.now();
    window[callbackName] = function(data) {
        delete window[callbackName];
        document.body.removeChild(script);
        callback(data);
    };
    script.src = `${url}?callback=${callbackName}`;
    document.body.appendChild(script);
}

方案四：postMessage（跨文档通信）★★★☆☆

场景：用于解决不同源的 iframe 之间 或新窗口与父窗口之间的通信。

示例：父页面监听 message 事件，子页面使用 window.parent.postMessage() 发送数据。

javascript 复制代码

// 父页面（http://a.com）
window.addEventListener('message', (e) => {
    if (e.origin !== 'http://b.com') return;
    console.log('收到子页面数据：', e.data);
});

// 子页面（http://b.com）
window.parent.postMessage({ type: 'ready', data: 'hello' }, 'http://a.com');

四、完整流程图 ------ 跨域请求到底发生了什么？

下面用 Mermaid 流程图展示一个简单的 GET 跨域请求 （非预检请求）和带预检的 POST 请求的区别。
后端服务器浏览器后端服务器浏览器发起 GET 跨域请求对比源，通过后放行发起 PUT/DELETE 或带自定义头的请求请求头 Origin: http://front.com 响应头 Access-Control-Allow-Origin: http://front.com 预检 OPTIONS 请求返回允许的方法和头部实际 PUT 请求实际响应
是
否
是
是
否
否
是
否
前端发起请求
是否同源？
请求成功，正常返回
是否为简单请求？
浏览器直接发送请求
服务器返回 CORS 头
Access-Control-Allow-Origin 是否包含前端源？
浏览器拦截，控制台报错
浏览器先发送 OPTIONS 预检
预检通过？

五、其他备选方案

方案	原理	适用场景	缺点
document.domain	将同主站下的子域名（如 `a.xx.com`、`b.xx.com`）的 `document.domain` 设为相同值	同一个主域下的不同子域之间跨域	有安全风险，且不能跨主域
window.name	利用 `window.name` 在页面跳转后仍然保留的特性，结合 iframe 做数据中转	老旧浏览器兼容	实现复杂，不推荐
WebSocket	WebSocket 协议本身不限制源	需要全双工实时通信的场景	需要后端支持 WebSocket
Chrome 插件跨域	插件拥有更高的权限，可以请求跨域资源	浏览器扩展开发	依赖插件环境

六、总结与最佳实践

首选 CORS：它是 W3C 标准，支持所有 HTTP 方法，配置简单，适合绝大多数生产环境。
开发环境用代理：快速省事，不污染生产代码。
生产环境推荐用 Nginx 反向代理 + CORS 头：既能统一管理跨域策略，又能减轻后端应用服务器的负担。
JSONP 仅用于 GET 且无需维护的旧系统：新项目请直接跳过。
注意预检请求的优化 ：Access-Control-Max-Age 可以缓存预检结果，减少不必要的 OPTIONS 请求。

在实际项目中，理解跨域的本质能帮你快速定位问题：是浏览器拦截了响应，而不是请求没发出去。所以抓包工具（如 Charles、Wireshark）依然能看到请求到达服务器并返回了数据，只是浏览器"扣留"了结果。