文章目录一、前言二、先搞懂核心什么是跨域为什么后端才能根治1. 跨域的本质不是后端不让访问是浏览器不让过2. 什么是CORS三、本地开发环境前端配Proxy代理后端要不要管跨域1. 前端代理的核心原理2. 前端开发环境完整代理配置实例Vue/React① Vue项目代理配置vue.config.js② React项目代理配置setupProxy.js3. 关键结论四、线上生产环境两类方案详解Nginx代理 / 后端代码CORS方案一线上Nginx配置代理跨域95%生产项目首选1. 适用场景2. 完整Nginx实操配置实例3. 核心优缺点4. 关键结论方案二后端SpringBoot代码配置CORS跨域特殊备用场景1. 适用场景2. SpringBoot全局CORS实操配置实例生产可用3. 核心优缺点4. 关键结论五、生产环境三种场景全覆盖总结直接背一、前言做SpringBootVue/React前后端分离开发**跨域CORS**是每个开发者必遇的问题。但很多人一直搞不懂三个核心灵魂问题为什么跨域明明是前端调后端接口却要后端来解决本地开发的时候前端配了Proxy代理后端还需要处理跨域吗线上项目用了Nginx反向代理后端SpringBoot/Gateway还要不要开CORS跨域配置能不能两边都配二、先搞懂核心什么是跨域为什么后端才能根治1. 跨域的本质不是后端不让访问是浏览器不让过浏览器有一个同源策略安全机制规定协议、域名、端口号三个必须完全一致才叫同源浏览器正常放行请求。只要有一个不一样就是跨域。常见跨域场景前端http://localhost:8080后端http://localhost:8090端口不同 → 妥妥跨域。重点牢记跨域不是后端接口拒绝了你是浏览器拿到后端响应后觉得不安全直接拦截丢弃了响应数据。前端代码再怎么改也绕不开浏览器的安全规则所以跨域的最终根治方案永远只能靠服务端后端/Nginx授权。2. 什么是CORS**CORS跨域资源共享**就是服务端通过返回特殊响应头告诉浏览器这个域名的跨域请求是我信任的你别拦截直接放行。浏览器看到合法的CORS响应头就不会拦截跨域请求前后端就能正常联调交互。三、本地开发环境前端配Proxy代理后端要不要管跨域1. 前端代理的核心原理日常开发我们都是前端本地启动localhost:8080后端本地启动localhost:8090前端配置devServer代理把/stage-api/这类接口请求转发到后端8090前端请求代码写的是/stage-api/xxx看似调后端实际流程是浏览器请求前端本地服务localhost:8080/stage-api/xxx前端代理拦截这个请求偷偷转发给后端localhost:8090后端返回数据代理原路还给浏览器2. 前端开发环境完整代理配置实例Vue/React本地开发核心核心原则前端本地启代理抹平端口和域名差异全程无真实跨域后端无需新增任何跨域相关代码专注业务接口开发即可。下面附上Vue、React项目开箱即用的代理配置复制改改后端端口就能直接用。① Vue项目代理配置vue.config.js适用于Vue2/Vue3常规前后端分离开发统一匹配前端接口请求前缀/stage-api无缝转发至本地SpringBoot后端服务。module.exports{// 关闭生产环境sourceMap减少打包体积productionSourceMap:false,devServer:{// 开启本地代理核心配置proxy:{// 匹配所有 /stage-api 开头的接口请求/stage-api:{// 目标地址本地SpringBoot后端服务地址target:http://localhost:8090,// 开启跨域代理伪装修改请求头origin为目标后端地址changeOrigin:true,// 路径重写前端请求带/stage-api后端接口不带该前缀自动剔除转发pathRewrite:{^/stage-api:}}}}}② React项目代理配置setupProxy.jsReact项目需手动新建src/setupProxy.js配置代理配置逻辑和Vue一致适配React本地开发跨域规避需求。const{createProxyMiddleware}require(http-proxy-middleware);module.exportsfunction(app){app.use(/stage-api,createProxyMiddleware({// 目标后端服务地址target:http://localhost:8090,changeOrigin:true,pathRewrite:{^/stage-api:}}));};3. 关键结论浏览器全程只访问了同源的8080前端本地服务根本没有发生真实跨域既然没有跨域行为浏览器不会触发跨域拦截校验后端SpringBoot完全不需要任何跨域配置、不用CrossOrigin、不用全局CORS配置啥都不用写。浏览器全程只访问了同源的8080根本没有发生跨域既然没有跨域浏览器就不会拦截请求后端SpringBoot完全不需要任何跨域配置、不用CrossOrigin、不用全局CORS配置啥都不用写。四、线上生产环境两类方案详解Nginx代理 / 后端代码CORS项目打包上线后前端本地开发代理会失效代理仅dev环境生效必须选择一种线上标准方案处理跨域。线上只分方案一Nginx反向代理统一处理跨域企业主流推荐、方案二后端代码配置CORS处理跨域特殊场景备用二选一即可严禁同时启用。方案一线上Nginx配置代理跨域95%生产项目首选核心架构前端静态页面、后端接口共用同一个域名由Nginx作为统一入口浏览器访问天然同源跨域直接在Nginx层拦截处理和后端代码完全解绑后端无需任何跨域改造。1. 适用场景前后端部署在同一台服务器、企业常规线上架构、需要统一管控接口流量、不想修改后端业务代码的所有项目。2. 完整Nginx实操配置实例server { listen 80; # 线上统一业务域名 server_name xxx.你的业务域名.com; # 转发前端静态页面资源 location / { root /usr/local/nginx/html/front; index index.html; try_files $uri $uri/ /index.html; } # 匹配所有后端接口请求统一处理跨域代理转发 location /stage-api/ { # 生产安全配置不使用*仅允许自家前端域名访问 add_header Access-Control-Allow-Origin http://xxx.你的业务域名.com; add_header Access-Control-Allow-Methods GET, POST, PUT, DELETE, OPTIONS; add_header Access-Control-Allow-Headers dnt,x-mx-reqtoken,keep-alive,user-agent,x-requested-with,if-modified-since,cache-control,content-type,authorization; # 允许携带Cookie、Token凭证 add_header Access-Control-Allow-Credentials true; # 直接拦截浏览器OPTIONS预检请求Nginx直接返回204不转发后端 if ($request_method OPTIONS) { return 204; } # 标准反向代理配置转发至后端网关/SpringBoot服务 proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header REMOTE-HOST $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://gateway_server/; } } # 后端服务集群上游配置 upstream gateway_server { server 127.0.0.1:8090; }3. 核心优缺点✅ 优点跨域统一运维管控、不侵入后端代码、性能好、安全可控、后续改域名只改Nginx无需重启服务❌ 缺点需要运维配合配置Nginx简单运维操作即可无其他额外成本。4. 关键结论Nginx已全权接管跨域所有处理工作后端SpringBoot、Gateway无需编写任何CORS代码零配置即可。方案二后端SpringBoot代码配置CORS跨域特殊备用场景核心逻辑无Nginx统一代理前后端是完全不同的两个独立域名浏览器直接跨域请求由后端通过代码添加CORS响应头授权浏览器放行跨域请求。1. 适用场景前后端分属不同公司域名部署、无Nginx运维干预、临时快速上线测试项目、第三方接口对外提供访问的场景。2. SpringBoot全局CORS实操配置实例生产可用推荐全局配置类方式一劳永逸不推荐注解方式注解需每个控制器逐个添加维护麻烦。importorg.springframework.context.annotation.Configuration;importorg.springframework.web.servlet.config.annotation.CorsRegistry;importorg.springframework.web.servlet.config.annotation.WebMvcConfigurer;/** * 生产环境后端全局CORS跨域配置 * 仅无Nginx代理的特殊场景使用 */ConfigurationpublicclassCorsConfigimplementsWebMvcConfigurer{OverridepublicvoidaddCorsMappings(CorsRegistryregistry){// 匹配后端所有接口路径registry.addMapping(/**)// 生产安全配置指定前端具体域名禁止使用*.allowedOrigins(http://xxx.你的前端域名.com)// 允许所有请求方法.allowedMethods(GET,POST,PUT,DELETE,OPTIONS)// 允许携带Token、Cookie等凭证.allowCredentials(true)// 预检请求缓存有效期1小时.maxAge(3600)// 允许所有请求头.allowedHeaders(*);}}3. 核心优缺点✅ 优点无需依赖Nginx运维代码层面直接搞定跨域部署简单❌ 缺点侵入业务代码后续修改前端域名需改代码重启服务安全性和统一运维性不如Nginx方案。4. 关键结论后端代码配置CORS后Nginx绝对不能再加任何跨域头否则重复响应头直接线上报错。绝对不能千万不要如果Nginx加了跨域头后端SpringBoot又配了全局CORS或者CrossOrigin注解浏览器会收到两份重复的Access-Control-Allow-Origin响应头直接报错The ‘Access-Control-Allow-Origin’ header contains multiple values浏览器不知道该信任哪一个直接拦截请求项目线上直接崩掉。跨域永远只允许「一个地方处理」要么前端开发代理、要么Nginx线上处理、要么后端CORS三选一绝不混用。五、生产环境三种场景全覆盖总结直接背运行环境跨域处理方式后端是否需要配CORS适用场景本地开发联调前端Vue/React配置devServer本地代理❌ 不需要日常前后端本地联调开发线上生产环境Nginx配置反向代理跨域头推荐❌ 不需要95%企业正规线上项目前后端统一域名部署线上生产环境后端SpringBoot代码配置全局CORS✅ 必须配前后端独立域名、无Nginx统一代理的特殊场景