微服务下的跨域问题

在单体架构时代跨域问题还不算突出但进入微服务、前后端分离、多端统一时代跨域几乎是每个项目必踩的坑。尤其在微服务架构下网关、认证、分布式部署、多域名并存让跨域变得更复杂、更隐蔽。本文从浏览器同源策略讲起结合微服务真实场景把跨域原理、常见方案、网关统一处理、避坑要点一次性讲透适合直接发布 CSDN 学习与收藏。一、什么是跨域为什么会出现跨域1.1 同源策略Same-Origin Policy跨域限制本质是浏览器的安全机制服务器本身不存在跨域限制。同源 协议 域名 端口 三者完全一致只要有一个不一样浏览器就判定为 “跨域”会拦截响应前端拿不到数据。举例以http://a.com:8080为基准表格请求地址是否跨域原因http://a.com:8080/api否完全同源https://a.com:8080/api是协议不同http/httpshttp://api.a.com:8080是域名不同http://a.com:9090/api是端口不同1.2 为什么微服务更容易跨域微服务天生就是多应用、多域名、多端口、多实例部署前端http://localhost:8080网关http://gateway:8888用户服务http://user:8001订单服务http://order:8002只要前端直接 / 间接访问非同源地址就会触发跨域。典型报错plaintextAccess to XMLHttpRequest at xxx from origin xxx has been blocked by CORS policy: No Access-Control-Allow-Origin header is present on the requested resource.二、跨域核心知识点简单请求 预检请求2.1 简单请求满足以下全部条件为简单请求方法GET / HEAD / POST请求头只包含Accept、Accept-Language、Content-Type等Content-Type 仅限application/x-www-form-urlencodedmultipart/form-datatext/plain特点只发一次请求直接携带跨域头。2.2 预检请求OPTIONS不满足简单请求就会触发预检自定义请求头如tokenContent-Type: application/json使用PUT / DELETE / PATCH浏览器会先发一次OPTIONS请求询问服务器允许哪些来源允许哪些方法允许哪些头服务器通过后才发送真实请求。微服务常见坑后端只处理了真实请求没处理 OPTIONS导致跨域一直失败。三、微服务架构下跨域的常见解决方案方案 1前端代理开发环境专用Vue / React / Angular 都支持devServer.proxy。原理前端请求自己 → 代理转发到后端 → 浏览器认为同源示例vue.config.jsjsdevServer: { proxy: { /api: { target: http://localhost:8888, changeOrigin: true } } }适用仅限开发环境生产环境不能用方案 2单个服务配置 CORS不推荐微服务在每个微服务中单独配置跨域。Spring Boot 示例java运行Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOrigins(*) .allowedMethods(GET,POST,PUT,DELETE,OPTIONS) .allowCredentials(true) .maxAge(3600); } }缺点每个服务都要写一遍网关、认证、服务之间不一致维护爆炸不适合微服务方案 3网关统一处理跨域微服务标准方案 ✅微服务最佳实践网关统一处理跨域下游微服务关闭跨域配置。常见网关Spring Cloud GatewayGatewayNet / Ocelot.NETNginxKong / APISIXSpring Cloud Gateway 配置跨域示例yamlspring: cloud: gateway: globalcors: cors-configurations: [/**]: allowedOrigins: * allowedMethods: * allowedHeaders: * allowCredentials: true maxAge: 3600优点统一配置一处修改全局生效避免下游服务重复配置完美适配微服务方案 4Nginx 反向代理生产常用前端 → Nginx → 网关 → 微服务Nginx 配置plaintextlocation /api/ { proxy_pass http://gateway:8888/; add_header Access-Control-Allow-Origin *; }适合对外正式环境多域名、多端统一接入方案 5JSONP淘汰只支持 GET不安全微服务基本不用。方案 6前端与后端同域名部署最彻底前端打包后放到后端静态资源目录或同域名 Nginx 代理。同源自然无跨域。四、微服务跨域高频坑点重点4.1 带 Cookie / Token 时跨域失效前端开启 withCredentialsjsaxios.defaults.withCredentials true后端必须Access-Control-Allow-Origin不能为*必须配置具体域名allowCredentials true4.2 OPTIONS 预检请求被拦截认证过滤器JWT/Security拦截 OPTIONS网关鉴权优先于跨域配置解决放行所有 OPTIONS 请求不做认证4.3 跨域头重复网关配置了跨域 微服务也配置了跨域导致响应头重复浏览器报错。原则网关处理跨域下游服务禁止再配置 CORS。4.4 开放 * 导致线上安全风险测试可用*生产必须指定具体域名。五、微服务跨域最佳实践总结开发环境前端代理微服务架构网关统一处理 CORS生产环境Nginx 反向代理 网关鉴权认证场景禁止 Origin*使用具体域名 allowCredentialsOPTIONS 请求统一放行不参与鉴权避免重复配置只在网关一层处理跨域六、结语跨域不是技术难题而是架构规范问题。在微服务里只要记住一句话跨域统一在网关处理下游服务只负责业务不关心跨域。这套方案能适配Spring Cloud、.NET 微服务、Go 微服务、K8s 集群、Service Mesh 等所有现代架构。