JavaScript Ajax请求遇到CORS跨域报错怎么解决

一、CORS 跨域报错的典型表现与底层机制

在前端控制台中最常见的报错提示如下：

Access to XMLHttpRequest at 'https://api.example.com/user/info' from origin 'http://localhost:3000' 
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

理解 CORS（Cross-Origin Resource Sharing，跨源资源共享）报错，必须先明确浏览器的同源判定准则与拦截执行时机：

1. 什么是同源（Same-Origin）

所谓“源”（Origin），由协议（Protocol）、域名或主机名（Host）、端口（Port）三部分共同组成。只有当这三者完全相同，浏览器才视其为同源。只要其中任何一项不一致，即属于跨域请求：

• http://example.com 与 https://example.com（协议不同：HTTP vs HTTPS，跨域）；
• http://example.com:8080 与 http://example.com:3000（端口不同，跨域）；
• http://blog.example.com 与 http://api.example.com（二级域名不同，跨域）；
• http://localhost:8080 与 http://127.0.0.1:8080（主机名不同，跨域）。

2. 核心事实：拦截发生在浏览器端，非服务端宕机

很多开发者误以为出现 CORS 错误是由于请求没有发送出去或服务端崩溃。事实恰恰相反：在多数情况下，Ajax 请求已经顺利通过网络到达后端，后端的业务逻辑与数据库更新也已经执行完毕并返回了 HTTP 200 响应。然而，当响应数据包返回到浏览器后，浏览器的同源安全引擎检查发现响应头中缺失 Access-Control-Allow-Origin 标识，出于保护用户隐私的同源策略，浏览器主动扣留了该数据包，禁止交付给前端 JavaScript 代码，并在控制台记录红字报错。

二、排查第一步：区分简单请求与预检请求（Preflight）

在定位具体为何被拦截前，需要确认该请求属于“简单请求”还是“预检请求”。W3C 规范对两者的处理方式存在显著差异：

现代化 Web 应用多采用前后端分离架构，前端 Ajax 提交数据普遍采用 Content-Type: application/json 或在 Header 中携带 JWT Token，因此绝大多数请求都会触发 OPTIONS 预检请求。如果服务端的路由网关或拦截器未能正确放行 OPTIONS 请求（如直接拦截并返回了 401 或 403），真正的业务请求甚至根本没有机会发出。

三、生产环境标准解决方案：服务端配置 CORS 响应头

解决跨域的根本途径在于目标服务端明确告知浏览器允许哪些源发起访问。以下梳理主流技术栈的具体配置操作：

1. Node.js (Express / Koa) 环境配置

在 Express 中，最稳妥的做法是引入官方维护的 cors 中间件，并显式指定来源白名单：

const express = require('express');
const cors = require('cors');
const app = express();

// 允许的前端源白名单列表
const allowlist = ['http://localhost:3000', 'https://webapp.example.com'];

const corsOptionsDelegate = (req, callback) => {
  let corsOptions;
  const origin = req.header('Origin');
  if (allowlist.indexOf(origin) !== -1) {
    // 明确回显允许的 Origin，并支持携带有状态凭据
    corsOptions = { 
      origin: origin, 
      credentials: true,
      methods: ['GET', 'POST', 'PUT', 'DELETE', 'OPTIONS'],
      allowedHeaders: ['Content-Type', 'Authorization', 'X-Requested-With'],
      maxAge: 86400 // 缓存预检结果 24 小时
    };
  } else {
    corsOptions = { origin: false };
  }
  callback(null, corsOptions);
};

app.use(cors(corsOptionsDelegate));

// 必须确保业务接口在 CORS 中间件之后挂载
app.get('/api/user', (req, res) => {
  res.json({ code: 200, message: '请求成功' });
});

app.listen(8080);

2. Nginx 反向代理配置（推荐微服务与网关层）

在统一反向代理层配置，可以一次性解决下游多个微服务的跨域支持。需要格外注意对 OPTIONS 请求直接返回 HTTP 204：

server {
    listen 80;
    server_name api.example.com;

    location / {
        # 拦截 OPTIONS 预检请求直接应答
        if ($request_method = 'OPTIONS') {
            add_header 'Access-Control-Allow-Origin' $http_origin always;
            add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;
            add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization' always;
            add_header 'Access-Control-Allow-Credentials' 'true' always;
            add_header 'Access-Control-Max-Age' 86400 always;
            add_header 'Content-Type' 'text/plain; charset=utf-8';
            add_header 'Content-Length' 0;
            return 204;
        }

        # 正式业务请求添加 CORS 响应头
        add_header 'Access-Control-Allow-Origin' $http_origin always;
        add_header 'Access-Control-Allow-Credentials' 'true' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;
        add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization' always;

        proxy_pass http://127.0.0.1:8080;
    }
}

3. Java Spring Boot 环境配置

在 Spring Boot 中，全局配置通常实现 WebMvcConfigurer 接口：

@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                // 使用 allowedOriginPatterns 支持细粒度域名校验
                .allowedOriginPatterns("http://localhost:3000", "https://*.example.com")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

四、本地开发环境解决方案：配置开发服务器代理（Proxy）

在前后端联调的本地开发阶段，若后端开发人员尚未部署完毕 CORS 逻辑，前端开发者可通过构建工具自带的 Node.js 开发服务器搭建正向代理规避跨域问题。

原理说明：同源策略是浏览器强加在 Web 前端的安全沙箱机制。服务器与服务器之间的 HTTP 通信（例如 Node 开发服务器与后端的 Spring/Go 接口通信）并不经过浏览器同源引擎，因此天然不存在跨域问题。

1. Vite 工程化项目配置（vite.config.js）

import { defineConfig } from 'vite';

export default defineConfig({
  server: {
    port: 3000,
    proxy: {
      // 当请求路径以 /api 开头时触发代理
      '/api': {
        target: 'https://api.example.com', // 后端真实接口基础地址
        changeOrigin: true,                // 修改请求头中的 Host 为目标服务器地址
        rewrite: (path) => path.replace(/^\/api/, '') // 根据需要重写路径
      }
    }
  }
});

2. 前端请求代码书写要求

配置代理后，前端调用 Ajax 时不可再把远端绝对域名写死在代码中，而必须改用同源的相对路径：

// 错误写法：直接调用远端，依旧走浏览器跨域检查，代理不生效！
// fetch('https://api.example.com/user/info');

// 正确写法：调用本地相对路径，由 Vite 开发服务器拦截并代发
fetch('/api/user/info', {
  headers: {
    'Content-Type': 'application/json',
    'Authorization': 'Bearer ' + token
  }
})
.then(res => res.json())
.then(data => console.log('数据接收成功:', data));

五、高频踩坑场景与具体排查清单

六、如何验证跨域问题已真正修复

在完成配置后，请按照以下步骤在浏览器的开发者工具中进行验证，确认链路已彻底健康：

1. 打开 Chrome / Edge 浏览器的 DevTools（按 F12），切换到 Network（网络） 面板；
2. 勾选 Preserve log（保留日志） 和 Disable cache（停用缓存）；
3. 触发你的前端 Ajax / fetch 动作，在请求列表中观察：
   • 若有预检请求，列表中会首先出现一个同名但 Method 为 OPTIONS 的条目，其 Status 必须为 200 或 204；
   • 点击该条目，检查 Response Headers，确认包含 Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers 字段；
   • 随后出现的实际业务请求（如 POST /api/user），其 Status 状态码应为 200 OK，并在 Response 面板中可正常查看到返回的 JSON 数据结构；
4. 切换至 Console（控制台） 面板，确认红色的 blocked by CORS policy 报错已彻底消失，JavaScript 代码已能成功解构使用返回值。