1. 跨域问题的本质与常见场景第一次遇到跨域问题时我盯着浏览器控制台的红色报错信息足足发了五分钟呆。那个经典的No Access-Control-Allow-Origin header is present错误相信每个全栈开发者都见过。简单来说跨域是浏览器出于安全考虑实施的同源策略限制——当你的前端页面比如Vue应用运行在http://localhost:8080尝试访问不同源协议/域名/端口任一不同的后端接口比如http://api.example.com时就会触发这个限制。实际开发中最常见的三种跨域场景本地开发环境Vue开发服务器访问本地Java后端测试环境部署在Tomcat的Java应用访问独立部署的前端资源生产环境通过Nginx反向代理多个服务时的跨域处理我见过不少团队在每个环节都配置跨域结果反而导致更奇怪的跨域了两次的问题。正确的做法应该是根据实际部署架构选择最合适的单一控制点进行配置。2. Java后端的跨域配置实战2.1 Spring Boot的三种配置方式在Spring Boot项目中我推荐使用WebMvcConfigurer方式配置全局跨域这也是最灵活的方式。下面这个配置类是我在多个生产项目中验证过的Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOrigins(http://localhost:8080, https://prod.domain.com) .allowedMethods(GET, POST, PUT, DELETE) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }这里有几个关键参数需要注意allowedOrigins建议明确指定允许的前端地址而不是用通配符*allowCredentials当需要传递cookie时必须设为truemaxAge预检请求的缓存时间单位秒2.2 控制器级别的细粒度控制对于需要特殊处理的接口可以使用CrossOrigin注解实现方法级控制RestController RequestMapping(/special) public class SpecialController { CrossOrigin(origins https://partner.domain.com) GetMapping(/data) public ResponseEntitySpecialData getSpecialData() { // ... } }3. Tomcat服务器的跨域配置3.1 通过web.xml配置过滤器当你的应用部署在独立Tomcat时可以在web.xml中添加CORS过滤器filter filter-nameCorsFilter/filter-name filter-classorg.apache.catalina.filters.CorsFilter/filter-class init-param param-namecors.allowed.origins/param-name param-valuehttp://localhost:8080,https://prod.domain.com/param-value /init-param init-param param-namecors.allowed.methods/param-name param-valueGET,POST,PUT,DELETE,OPTIONS/param-value /init-param /filter3.2 常见陷阱与解决方案我遇到过Tomcat 9版本的特殊情况当同时使用Spring Security和Tomcat CORS过滤器时会出现配置冲突。解决方案是在Spring Security配置中明确禁用默认的CORS处理EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http.cors().disable(); // 其他安全配置... } }4. Nginx层的跨域处理4.1 基础配置模板Nginx作为反向代理时可以在server块中添加以下配置server { listen 80; server_name api.example.com; location / { add_header Access-Control-Allow-Origin $http_origin; add_header Access-Control-Allow-Methods GET, POST, PUT, DELETE, OPTIONS; add_header Access-Control-Allow-Headers DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization; add_header Access-Control-Expose-Headers Content-Length,Content-Range; add_header Access-Control-Allow-Credentials true; if ($request_method OPTIONS) { add_header Access-Control-Max-Age 1728000; add_header Content-Type text/plain; charsetutf-8; add_header Content-Length 0; return 204; } proxy_pass http://backend-service; } }4.2 动态origin的高级处理生产环境中经常需要根据请求来源动态设置允许的origin。这是我用过的一个巧妙方案map $http_origin $cors_origin { default ; ~^https://(.\.)?example\.com$ $http_origin; ~^http://localhost(:[0-9])?$ $http_origin; } server { # ... add_header Access-Control-Allow-Origin $cors_origin; # ... }5. Vue前端的跨域解决方案5.1 开发环境代理配置在vue.config.js中配置devServer.proxy可以完美解决开发时的跨域问题module.exports { devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true, pathRewrite: { ^/api: /api/v1 }, onProxyReq(proxyReq) { proxyReq.setHeader(X-Proxy-By, Vue-Dev-Server); } } } } }5.2 生产环境的最佳实践生产环境中我建议完全避免前端直接处理跨域问题而是应该将前端和后端部署在同一个域名下或者通过Nginx统一处理跨域对于第三方API调用考虑搭建BFF(Backend For Frontend)层6. 多层级配置的黄金法则经过多个项目的实践我总结出跨域配置的一条黄金法则只在架构的最外层处理跨域。具体来说纯前端开发时 → 使用Vue代理仅后端服务时 → 使用Spring配置Tomcat独立部署 → 使用Tomcat过滤器Nginx反向代理 → 使用Nginx配置最典型的反模式就是在Java、Tomcat和Nginx中都配置了跨域结果导致预检请求被多次处理响应头重复添加缓存控制失效我曾经排查过一个诡异的问题某些浏览器能正常访问而另一些不行。最后发现是因为多层跨域配置导致响应头重复不同浏览器的解析策略不同导致的。
从代码到部署：Java、Tomcat、Nginx与Vue中的跨域配置实战
1. 跨域问题的本质与常见场景第一次遇到跨域问题时我盯着浏览器控制台的红色报错信息足足发了五分钟呆。那个经典的No Access-Control-Allow-Origin header is present错误相信每个全栈开发者都见过。简单来说跨域是浏览器出于安全考虑实施的同源策略限制——当你的前端页面比如Vue应用运行在http://localhost:8080尝试访问不同源协议/域名/端口任一不同的后端接口比如http://api.example.com时就会触发这个限制。实际开发中最常见的三种跨域场景本地开发环境Vue开发服务器访问本地Java后端测试环境部署在Tomcat的Java应用访问独立部署的前端资源生产环境通过Nginx反向代理多个服务时的跨域处理我见过不少团队在每个环节都配置跨域结果反而导致更奇怪的跨域了两次的问题。正确的做法应该是根据实际部署架构选择最合适的单一控制点进行配置。2. Java后端的跨域配置实战2.1 Spring Boot的三种配置方式在Spring Boot项目中我推荐使用WebMvcConfigurer方式配置全局跨域这也是最灵活的方式。下面这个配置类是我在多个生产项目中验证过的Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOrigins(http://localhost:8080, https://prod.domain.com) .allowedMethods(GET, POST, PUT, DELETE) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }这里有几个关键参数需要注意allowedOrigins建议明确指定允许的前端地址而不是用通配符*allowCredentials当需要传递cookie时必须设为truemaxAge预检请求的缓存时间单位秒2.2 控制器级别的细粒度控制对于需要特殊处理的接口可以使用CrossOrigin注解实现方法级控制RestController RequestMapping(/special) public class SpecialController { CrossOrigin(origins https://partner.domain.com) GetMapping(/data) public ResponseEntitySpecialData getSpecialData() { // ... } }3. Tomcat服务器的跨域配置3.1 通过web.xml配置过滤器当你的应用部署在独立Tomcat时可以在web.xml中添加CORS过滤器filter filter-nameCorsFilter/filter-name filter-classorg.apache.catalina.filters.CorsFilter/filter-class init-param param-namecors.allowed.origins/param-name param-valuehttp://localhost:8080,https://prod.domain.com/param-value /init-param init-param param-namecors.allowed.methods/param-name param-valueGET,POST,PUT,DELETE,OPTIONS/param-value /init-param /filter3.2 常见陷阱与解决方案我遇到过Tomcat 9版本的特殊情况当同时使用Spring Security和Tomcat CORS过滤器时会出现配置冲突。解决方案是在Spring Security配置中明确禁用默认的CORS处理EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http.cors().disable(); // 其他安全配置... } }4. Nginx层的跨域处理4.1 基础配置模板Nginx作为反向代理时可以在server块中添加以下配置server { listen 80; server_name api.example.com; location / { add_header Access-Control-Allow-Origin $http_origin; add_header Access-Control-Allow-Methods GET, POST, PUT, DELETE, OPTIONS; add_header Access-Control-Allow-Headers DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization; add_header Access-Control-Expose-Headers Content-Length,Content-Range; add_header Access-Control-Allow-Credentials true; if ($request_method OPTIONS) { add_header Access-Control-Max-Age 1728000; add_header Content-Type text/plain; charsetutf-8; add_header Content-Length 0; return 204; } proxy_pass http://backend-service; } }4.2 动态origin的高级处理生产环境中经常需要根据请求来源动态设置允许的origin。这是我用过的一个巧妙方案map $http_origin $cors_origin { default ; ~^https://(.\.)?example\.com$ $http_origin; ~^http://localhost(:[0-9])?$ $http_origin; } server { # ... add_header Access-Control-Allow-Origin $cors_origin; # ... }5. Vue前端的跨域解决方案5.1 开发环境代理配置在vue.config.js中配置devServer.proxy可以完美解决开发时的跨域问题module.exports { devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true, pathRewrite: { ^/api: /api/v1 }, onProxyReq(proxyReq) { proxyReq.setHeader(X-Proxy-By, Vue-Dev-Server); } } } } }5.2 生产环境的最佳实践生产环境中我建议完全避免前端直接处理跨域问题而是应该将前端和后端部署在同一个域名下或者通过Nginx统一处理跨域对于第三方API调用考虑搭建BFF(Backend For Frontend)层6. 多层级配置的黄金法则经过多个项目的实践我总结出跨域配置的一条黄金法则只在架构的最外层处理跨域。具体来说纯前端开发时 → 使用Vue代理仅后端服务时 → 使用Spring配置Tomcat独立部署 → 使用Tomcat过滤器Nginx反向代理 → 使用Nginx配置最典型的反模式就是在Java、Tomcat和Nginx中都配置了跨域结果导致预检请求被多次处理响应头重复添加缓存控制失效我曾经排查过一个诡异的问题某些浏览器能正常访问而另一些不行。最后发现是因为多层跨域配置导致响应头重复不同浏览器的解析策略不同导致的。
