别再乱配CorsFilter了！SpringBoot项目打War包丢进Tomcat，跨域配置的正确姿势
SpringBoot项目War包部署到Tomcat的跨域配置避坑指南
当我们将SpringBoot应用打包成War部署到外部Tomcat时，跨域配置往往会成为令人头疼的问题。明明在内置容器中运行良好的配置，迁移到Tomcat后却突然失效。这背后其实是配置层级和过滤器优先级的问题，需要我们从Servlet容器和Spring应用两个层面来理解。
1. 理解War包部署的特殊性
SpringBoot默认以嵌入式容器方式运行，但企业环境中常要求打包为War部署到独立Tomcat。这种模式下，应用的运行环境发生了本质变化：
- 容器控制权转移：从SpringBoot内嵌容器变为外部Tomcat管理
- 配置作用域变化：原先在应用内的配置现在需要与容器配置协同
- 过滤器链差异：Tomcat自身的过滤器会先于应用过滤器执行
我曾在一个金融项目中就踩过这个坑——测试环境用jar包运行一切正常，上线部署为War后跨域突然失效，导致前端无法调用接口。经过排查才发现是Tomcat的默认配置覆盖了我们的跨域设置。
2. 跨域配置的三种层级
在War包部署场景下，跨域配置实际上存在三个可能的作用层级：
| 配置层级 | 配置方式 | 适用场景 | 优先级 |
|---|---|---|---|
| Tomcat全局 | 修改conf/web.xml | 需要统一管控所有应用 | 最低 |
| 应用web.xml | WEB-INF/web.xml | 传统Java Web项目方式 | 中等 |
| Spring配置 | @CrossOrigin/WebMvcConfigurer | Spring应用内部 | 最高 |
提示：当多个层级的配置同时存在时，高优先级的配置会覆盖低优先级的配置，这常常是跨域失效的根本原因。
3. 推荐的最佳实践方案
基于实际项目经验，我总结出以下几种可靠配置方案：
3.1 纯Spring方案（推荐）
完全依赖Spring的跨域支持，不在Tomcat做任何配置：
@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") .allowedOrigins("https://yourdomain.com") .allowedMethods("GET", "POST") .allowCredentials(true); } }优势：
- 配置完全在应用内，不受部署方式影响
- 细粒度控制每个API的跨域规则
- 便于不同环境差异化配置
3.2 过滤器方案（适合老项目）
对于还在使用传统web.xml配置的项目：
<!-- WEB-INF/web.xml --> <filter> <filter-name>corsFilter</filter-name> <filter-class>com.yourpackage.CustomCorsFilter</filter-class> </filter> <filter-mapping> <filter-name>corsFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>对应的过滤器实现：
public class CustomCorsFilter implements Filter { @Override public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException { HttpServletResponse response = (HttpServletResponse) res; response.setHeader("Access-Control-Allow-Origin", "*"); response.setHeader("Access-Control-Allow-Methods", "POST, GET, PUT, OPTIONS, DELETE"); response.setHeader("Access-Control-Max-Age", "3600"); response.setHeader("Access-Control-Allow-Headers", "Content-Type, Authorization"); chain.doFilter(req, res); } }3.3 混合方案的特殊处理
当Tomcat同时服务静态资源和War包时，需要特别注意：
- 在Tomcat的conf/web.xml中注释掉默认的CORS过滤器配置
- 在应用中统一管理跨域规则
- 静态资源通过Nginx等前置代理处理跨域
4. 常见问题排查指南
遇到跨域问题时，建议按照以下步骤排查：
确认请求是否到达后端
- 查看Tomcat访问日志
- 检查是否有5xx错误
检查响应头信息
curl -I http://yourserver.com/api观察返回的Access-Control-*头是否符合预期
验证配置加载顺序
- Tomcat启动时加载的过滤器
- 应用初始化时加载的配置类
特殊场景测试
- 带Cookie的请求(需设置allowCredentials)
- 非简单请求(PUT/DELETE等)的预检请求
在一次电商平台的项目中，我们遇到了一个棘手的案例：Chrome正常但Safari跨域失败。最终发现是因为Safari对CORS的实现更严格，必须明确列出所有允许的Headers。这个教训告诉我们，跨浏览器测试同样重要。
5. 性能与安全考量
跨域配置不当不仅会导致功能问题，还可能引入安全风险：
- 过度开放的配置：使用
*作为允许来源在生产环境是危险的 - 重复配置：多个层级的CORS过滤器会增加不必要的性能开销
- 缓存问题：预检请求的maxAge设置过长可能导致策略更新延迟
建议的安全实践：
- 精确指定allowedOrigins而非使用通配符
- 开发和生产环境使用不同的CORS策略
- 定期审计API的跨域访问权限
对于需要高安全性的系统，可以考虑：
.allowedOrigins(Arrays.asList( "https://prod.yourdomain.com", "https://staging.yourdomain.com" ))6. 现代架构的替代方案
随着架构演进，一些现代方案可以避免CORS问题：
- API Gateway：在网关层统一处理跨域
- BFF模式：为前端定制API，避免直接跨域调用
- 反向代理：通过Nginx等将前后端路由到同源
在微服务架构中，我们通常会在Spring Cloud Gateway中这样配置：
spring: cloud: gateway: globalcors: cors-configurations: '[/**]': allowedOrigins: "https://yourdomain.com" allowedMethods: "*"这些方案将跨域问题从应用层提升到架构层解决，使应用代码更加纯粹。