前端跨域请求详解：原理剖析与四种解决方案

一、跨域从何而来：先搞懂同源策略

很多开发者第一次遇到跨域，都是在浏览器控制台看到一片鲜红的 CORS 报错，然后开始四处搜索“怎么解决”。但要想彻底解决问题，必须先理解它的来龙去脉。

1. 什么是“同源”

同源策略是浏览器最核心、最基础的安全机制。所谓“同源”，要求以下三个要素完全一致：

• 协议（http / https）
• 域名
• 端口号

三要素中任何一个不同，浏览器就判定为“不同源”。举几个典型例子：

页面所在源	请求目标	是否同源	原因
http://localhost:8080	http://localhost:8080/api/list	同源	三要素一致
http://localhost:8080	http://localhost:5000/api/list	跨域	端口不同
http://a.com	https://a.com	跨域	协议不同
http://a.com	http://b.com	跨域	域名不同

2. 一个最典型的场景

本地开发前后端分离项目时：前端页面跑在 http://localhost:8080，后端接口跑在 http://localhost:5000。虽然都叫 localhost，但端口一个是 8080、一个是 5000，在浏览器眼里就是“两家人”。当前端代码伸手去拿 5000 的数据时，浏览器会立刻拦截——这一拦，就叫跨域。

这里有一个非常关键却常被忽略的认知：跨域拦截发生在“响应”阶段，而不是“请求”阶段。请求实际上已经发出、后端也正常处理并返回了数据，只是浏览器校验响应后，发现后端没有声明“允许当前源访问”，于是拒绝把数据交给页面代码。这也是为什么在网络面板中，跨域失败的请求有时状态看起来正常，页面却拿不到数据。

3. 浏览器为什么要设置这道防线

设想一下：如果没有同源策略，你刚登录某网站，随后打开另一个恶意页面，该页面就能挟持你的登录态向那个网站发起请求并读取响应，窃取隐私数据、执行危险操作——这正是典型的 CSRF 与数据窃取攻击路径。同源策略把不同源的数据严格隔离，是整个 Web 安全的基石。

所以请建立一个正确观念：跨域不是 Bug，而是安全设计。我们要做的不是“对抗”它，而是通过受控、合法的方式完成跨源通信。

二、方案一：开发环境代理（本地联调首选）

1. 原理：找一位“中间商”

同源策略只约束浏览器，不约束服务器。前端开发服务器本身是一个跑在本地服务端的程序，它对外发请求时完全不受同源策略限制。于是思路就清晰了：

浏览器 → 开发服务器(8080) → 后端服务(5000)
浏览器 ← 开发服务器(8080) ← 后端服务(5000)

浏览器自始至终只和 8080 打交道，对它来说请求永远同源；真正的跨源动作由开发服务器在服务端完成。这就是代理方案能生效的根本原因。

2. 配置示例

在前端工程根目录的构建配置文件中添加代理规则（不同构建工具的字段名略有差异，以下为通用示意，具体以所用工具的官方文档为准）：

module.exports = {
  devServer: {
    proxy: {
      '/api': {                          // 凡是 /api 开头的请求，一律代理
        target: 'http://localhost:5000', // 后端真实地址
        changeOrigin: true,              // 将请求头中的 Host 改写为目标地址
        pathRewrite: { '^/api': '' }     // 剥离 /api 前缀，与后端路由对齐
      }
    }
  }
}

字段含义说明：

• target：代理目标，即后端接口的真实地址；
• changeOrigin：把请求头里的 Host 改写为目标地址。部分后端会校验 Host，建议开启；
• pathRewrite：路径重写。例如请求 http://localhost:8080/api/user/list，转发后会变成 http://localhost:5000/user/list。

3. 请求写法的变化

// ❌ 直接写后端完整地址，会被浏览器拦截
request.get('http://localhost:5000/user/list')
// ✅ 请求同源的 /api 前缀，由开发服务器代为转发
request.get('/api/user/list')

4. 注意事项

• 修改代理配置后必须重启开发服务器才能生效；
• 建议在项目初期就约定统一的 /api 前缀作为接口命名空间，方便代理匹配；
• 代理只在开发环境生效，打包部署后配置即失效，生产环境需要另外的方案（见方案三）。

三、方案二：后端开启 CORS（标准方案）

1. 原理：让后端“亮明态度”

CORS（跨域资源共享）是 Web 标准定义的官方机制：后端通过响应头显式声明“允许哪些源访问我”，浏览器校验通过后放行数据。与代理的“绕道”思路不同，CORS 是从源头上获得授权，是浏览器原生支持的跨源方案。

2. 简单请求与预检请求

并非所有跨域请求都会直接发出，浏览器将请求分为两类：

• 简单请求：方法为 GET / POST / HEAD，不携带自定义请求头，Content-Type 限于表单编码、纯文本等，浏览器直接发送；
• 非简单请求：例如携带 Authorization 头、或 Content-Type 为 application/json 的请求，浏览器会先发送一个 OPTIONS 预检请求，询问服务器是否允许，得到肯定答复后才发送真正的请求。

这就是联调时经常看到“同一个接口请求发了两次，先 OPTIONS 再真正请求”的原因。

3. 关键响应头一览

Access-Control-Allow-Origin: http://localhost:8080   // 允许的来源
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true               // 允许携带 Cookie
Access-Control-Max-Age: 3600                         // 预检结果缓存时长

4. 后端中间件示意

// 伪代码示意，具体写法以所用后端框架为准
app.use((req, res, next) => {
  res.setHeader('Access-Control-Allow-Origin', 'http://localhost:8080')
  res.setHeader('Access-Control-Allow-Methods', 'GET,POST,PUT,DELETE,OPTIONS')
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type,Authorization')
  res.setHeader('Access-Control-Allow-Credentials', 'true')
  if (req.method === 'OPTIONS') {
    return res.sendStatus(204) // 预检请求直接返回，不进入业务逻辑
  }
  next()
})

5. 携带 Cookie 时的大坑

当请求需要携带 Cookie 时，Access-Control-Allow-Origin 不能设为通配符 *，必须写明确的具体来源；同时前端请求也要显式开启 credentials 选项，后端在预检响应中同样要声明允许 credentials。这是实际项目中最常见的跨域报错之一。

四、方案三：生产环境反向代理

1. 为什么生产环境需要它

开发环境的代理配置不会随构建产物一起发布。项目上线后，最干净的做法是在网关层做反向代理：把前端静态资源和后端接口收敛到同一个域名下，由网关统一分发。对浏览器而言，页面和接口天然同源，跨域问题从架构层面直接消失。

2. 配置思路示意

server {
  listen 80;
  # 接口请求转发给后端服务
  location /api/ {
    proxy_pass http://127.0.0.1:5000/;
  }
  # 其余请求返回前端静态资源
  location / {
    root /var/www/app;
    index index.html;
  }
}

3. 核心优势

• 对前端代码零侵入：生产环境请求依然写 /api 前缀，与开发环境完全一致，无需按环境切换接口地址；
• 能力扩展：网关层可以顺带承担负载均衡、HTTPS 卸载、静态资源缓存、压缩等职责；
• 更安全：后端服务的真实地址不必暴露给公网。

五、方案四：JSONP（历史方案，了解即可）

1. 原理

JSONP 利用了一个历史“漏洞”：script 标签加载脚本不受同源策略限制。前端先定义好回调函数，把函数名通过参数传给后端，后端把数据包裹在函数调用中返回，脚本一执行，数据就到手了。

function handleData(data) {
  console.log('拿到跨域数据：', data)
}
const script = document.createElement('script')
script.src = 'http://localhost:5000/user/list?callback=handleData'
document.body.appendChild(script)

2. 局限性

• 只支持 GET 请求，无法满足写操作；
• 需要后端专门配合拼接回调函数名；
• 存在脚本注入等安全隐患，回调名等入参必须严格校验。

如今新项目基本不再使用 JSONP，只有在对接仅支持这种形式的老旧接口时才会用到。

六、补充：其他跨源通信手段

• postMessage：页面与 iframe、新开窗口之间跨源通信的标准 API，适用于窗口间消息传递，而非接口请求场景；
• WebSocket：建立连接时不受同源策略限制（握手走独立协议），适合实时双向通信的业务。

七、方案选型速查表

场景	推荐方案
本地开发联调	开发服务器代理
生产环境前后端分离部署	反向代理（首选）或后端 CORS
后端可改造、需精细控制来源白名单	CORS
对接仅支持回调形式的老旧接口	JSONP
iframe / 窗口间通信	postMessage

八、常见踩坑清单

1. 只配了开发代理，上线后跨域：代理配置不随构建产物生效，生产必须另行配置反向代理或 CORS；
2. 携带 Cookie 报错：Allow-Origin 不能是通配符，前后端都要开启 credentials；
3. OPTIONS 返回 401/500：后端把预检请求当业务请求处理了，应在鉴权逻辑之前对 OPTIONS 短路返回；
4. 改了代理配置没反应：需要重启开发服务器；
5. 转发后 404：pathRewrite 规则与后端路由不匹配，检查前缀剥离逻辑；
6. 预检请求过于频繁：通过 Access-Control-Max-Age 缓存预检结果，减少 OPTIONS 次数。

九、总结

跨域的本质是浏览器的安全边界，而非前后端“闹矛盾”。解决思路归纳起来只有两条主线：要么让请求“看起来同源”（代理），要么让后端“明确授权”（CORS）。实践上，开发阶段用代理快速联调，生产阶段用反向代理统一入口，后端以 CORS 白名单兜底，携带 Cookie 时注意 credentials 细节，绝大多数跨域问题都能从容化解。理解原理远比死记配置重要——当你能一眼看出控制台报错对应哪一环时，跨域就再也不是拦路虎了。