别再被跨域搞心态，服务器修复实战指南

这事儿吧，其实就是个“门禁”问题

你有没有发现，前端代码在本地跑得好好的，一联调测试环境或者上线，控制台立马飘红？那种心情，简直比打排位遇到挂机还难受。报错信息千奇百怪，但核心往往就几个字：CORS policy。

说白了，这就是浏览器那个“多管闲事”的保安在作祟。它有个同源策略，规定你的前端（比如 localhost:8080）和后端（比如 api.server.com）如果不是同一个“户口”（协议、域名、端口完全一致），浏览器就会觉得这事儿不安全，直接把请求拦截下来。

很多人这时候会懵，明明接口通了，数据也返回了，为什么浏览器还是报错？因为浏览器觉得数据虽然到了，但没经过“门卫”同意，不能给你看。这就像你去朋友家串门，门卫没登记，你就算进去了，心里也不踏实，随时可能被赶出来。

要想彻底解决这事儿，咱们得绕过前端，直接在服务器（后端）这个“源头”上动手。毕竟，门禁系统得物业（服务器）来改，而不是访客（前端）来改。

Nginx 层面搞定：最常用的“万能钥匙”

绝大多数生产环境，前面都挂了个 Nginx。如果你有权限碰 Nginx 配置，恭喜你，这事儿解决了一半。

咱们得告诉 Nginx：只要是兄弟域名发来的请求，都给个通行证。这就需要在响应头里加几个关键字段。

```nginx server { listen 80; server_name your-api.com; location / { 关键点来了：允许谁访问？ 表示所有，生产环境建议指定域名 add_header Access-Control-Allow-Origin 'http://your-frontend.com'; 允许带哪些请求头？别吝啬，把常用的都加上 add_header Access-Control-Allow-Headers 'Authorization, Content-Type, X-Requested-With'; 允许哪些请求方法？GET, POST, PUT, DELETE... 别漏了 OPTIONS add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS, PUT, DELETE'; 如果你的接口需要带 Cookie（比如验证登录态），这一项必须开 add_header Access-Control-Allow-Credentials 'true'; 处理预检请求（OPTIONS），浏览器发试探性请求时直接返回 200 if ($request_method = 'OPTIONS') { return 204; } proxy_pass http://backend_server; } } ```

这里有个大坑，千万别掉进去。当你设置了 Access-Control-Allow-Credentials 'true' 的时候，Allow-Origin 就不能写通配符 了，必须写死具体的域名。这就像你要办贵宾卡，门卫必须确认你是张三还是李四，不能说“谁都可以办贵宾卡”，那系统就乱套了。

Node.js (Express) 中间件：代码里的“绿色通道”

如果你是用 Node.js 写的后端，或者还在开发阶段没上 Nginx，用中间件是最爽的。这就好比你在自家门口挂了个牌子：“朋友免进”，那肯定不行，得换成“欢迎光临”。

很多新手喜欢自己手写 res.header，其实没必要，容易漏。直接用现成的轮子 cors 库，省心又省力。

```javascript const express = require('express'); const cors = require('cors'); const app = express(); // 简单粗暴版：允许所有跨域（仅限开发环境玩玩） // app.use(cors()); // 生产环境推荐配置版 app.use(cors({ origin: 'http://your-frontend.com', // 指定前端域名 methods: ['GET', 'POST', 'PUT', 'DELETE'], // 允许的方法 allowedHeaders: ['Content-Type', 'Authorization'], // 允许的头部 credentials: true // 开启 Cookie 携带 })); app.get('/user', (req, res) => { res.json({ msg: '这就通了，是不是很简单？' }); }); app.listen(3000); ```

看到没？几行代码就搞定。那种看着控制台一片绿的清爽感，真的能让人心情变好。别再在那儿傻傻地配 JSONP 了，那都是老黄历了，而且只支持 GET，局限性太大。

Java (Spring Boot) 全局配置：一劳永逸

搞 Java 的兄弟们，别再在每个 Controller 方法上面加 @CrossOrigin 注解了，加得满屏都是，看着都乱。咱们要做就做全局配置，显得专业。

这就需要咱们重写一下 WebMvcConfigurer，给整个系统定个规矩。

```java import org.springframework.context.annotation.Configuration; import org.springframework.web.servlet.config.annotation.CorsRegistry; import org.springframework.web.servlet.config.annotation.WebMvcConfigurer; @Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/") // 对所有接口生效 .allowedOriginPatterns("http://your-frontend.com") // 注意这里用 allowedOriginPatterns 支持动态域名 .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("") .allowCredentials(true) // 开启凭证支持 .maxAge(3600); // 预检请求的有效期，1小时内不用再问，提升性能 } } ```

这里有个小细节，新版 Spring Boot 建议用 allowedOriginPatterns 代替 allowedOrigins，因为前者更强大，能处理一些复杂的正则匹配。这就像是门卫手里拿的名单升级了，不仅能认名字，还能认脸。

最后唠叨两句

跨域这东西，原理搞懂了其实就那么回事儿。别一看到红字就慌，也别总想着在前端 webpack 里配代理糊弄过去（虽然开发环境确实好用）。到了生产环境，还是得老老实实在服务器层面解决，这才是正道。

希望这篇废话少说、全是干货的文章能帮你省下几个小时的抓狂时间。搞完赶紧去喝杯咖啡，毕竟修 Bug 这种事儿，越早搞定越好，别让这玩意儿耽误了下班。