摘要：理论结合实践才能更好地掌握跨域配置，以下以 “Spring Boot3 后端 + Vue3 前端” 的前后端分离项目为例，展示不同场景下的跨域解决方案落地，覆盖开发环境、生产环境及与 Spring Security 整合的场景。
在之前的分享中，我们介绍了跨域问题的基础实现方式以及解决方案，这里我们继续基于上篇的内容给出实战以及技术选型案例
理论结合实践才能更好地掌握跨域配置，以下以 “Spring Boot3 后端 + Vue3 前端” 的前后端分离项目为例，展示不同场景下的跨域解决方案落地，覆盖开发环境、生产环境及与 Spring Security 整合的场景。
（一）开发环境：简化配置提升效率
开发环境中，前端通常运行在 http://localhost:8080，后端运行在 http://localhost:9090，需快速实现跨域调试，无需过度强调安全性：
后端全局 cors 配置：使用 WebMvcConfigurer 实现全局配置，允许前端本地地址跨域，同时允许所有常用方法和请求头，减少调试阻碍：
@Configurationpublic class DevCorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") // 仅对/api前缀的接口配置跨域（避免非业务接口暴露） .allowedOrigins("http://localhost:8080") // 开发环境仅允许前端本地地址 .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedheaders("*") .allowCredentials(true) .maxAge(3600); // 预检请求缓存1小时，减少重复请求 }}前端无需额外配置：Vue3 项目中使用 Axios 发送请求时，直接指定后端地址即可，无需添加跨域相关参数：
import axios from 'axios';const request = axios.create({ baseURL: 'http://localhost:9090/api', // 后端接口基础路径 timeout: 5000});// 示例：发送GET请求Request.get('/user/info').then(res => { console.log(res.data);}).catch(err => { console.error('请求失败：', err);});（二）生产环境：安全优先的精细化配置
生产环境中，前端部署在 https://www.frontend.com，后端部署在 https://api.backend.com，需严格限制跨域来源，避免恶意网站利用跨域漏洞：
后端配置指定允许的域名：将 allowedOrigins 设置为前端生产环境域名，同时限制请求头和方法，仅开放业务必需的配置：
@Configurationpublic class ProdCorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") .allowedOrigins("https://www.frontend.com") // 仅允许生产环境前端域名 .allowedMethods("GET", "POST", "PUT", "DELETE") // 禁用不必要的OPTIONS方法（生产环境中预检请求已缓存） .allowedHeaders("Content-Type", "Authorization") // 仅允许业务必需的请求头（如Content-Type、令牌头Authorization） .allowCredentials(true) .maxAge(86400); // 预检请求缓存24小时，降低服务器压力 }}配合 Nginx 反向代理优化性能：生产环境中，可通过 Nginx 配置反向代理，将前端对 /api 的请求转发到后端，避免浏览器直接发送跨域请求 —— 这种方式本质上是 “同源请求代理”，能减少 CORS 预检请求，提升性能。Nginx 配置示例：
server { listen 443 ssl; server_name www.frontend.com; # 前端域名 # ssl配置（省略） ssl_certificate /etc/nginx/ssl/frontend.crt; ssl_certificate_key /etc/nginx/ssl/frontend.key; # 反向代理后端API location /api/ { proxy_pass https://api.backend.com/api/; # 转发到后端地址 proxy_set_Header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } # 前端静态资源配置（省略） location / { root /usr/share/nginx/html/frontend; index index.html; try_files $uri $uri/ /index.html; # 适配Vue路由History模式 }}此时前端 Axios 的 baseURL 可设置为 /api（与前端同源），无需跨域配置，请求会通过 Nginx 转发到后端，既提升安全性，又减少跨域请求的性能损耗。
（三）整合 Spring Security 的跨域配置
若项目中使用 Spring Security 进行身份验证（如 JWT 令牌验证），需特别注意 CORS 配置与 Security 的兼容性 ——Spring Security 的拦截器优先级高于普通 CORS 过滤器，若未正确配置，会导致 CORS 响应头被 Security 拦截。
正确的配置步骤：
关闭 Security 的默认 CORS 配置：在 Spring Security 配置类中，通过 cors.disable 关闭默认 CORS 处理，避免与自定义 CORS 配置冲突。将 CORS 过滤器纳入 Security 过滤链：通过 addFilterBefore 方法，将自定义 CORS 过滤器添加到 Security 的 UsernamePasswordAuthenticationFilter 之前，确保 CORS 响应头在身份验证之前返回。具体代码示例：
@Configuration@EnableWebSecuritypublic class SecurityConfig { // 注入自定义CORS过滤器 @Autowired private SimpleCorsFilter corsFilter; @Bean public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { http .cors.disable // 关闭默认CORS配置 .csrf.disable // 前后端分离项目通常关闭CSRF（若使用JWT） .authorizeHttpRequests(auth -> auth .requestMatchers("/api/public/**").permitAll // 公开接口无需认证 .anyRequest.authenticated // 其他接口需认证 ) .addFilterBefore(corsFilter, UsernamePasswordAuthenticationFilter.class); // 将CORS过滤器添加到Security过滤链 return http.build; }}此外，需确保 Security 允许 OPTIONS 预检请求 —— 由于 OPTIONS 请求不携带令牌，若 Security 拦截 OPTIONS 请求，会导致预检失败。可在 authorizeHttpRequests 中添加 requestMatchers(HttpMethod.OPTIONS, "/**").permitAll，允许所有 OPTIONS 请求匿名访问：
.authorizeHttpRequests(auth -> auth .requestMatchers(HttpMethod.OPTIONS, "/**").permitAll // 允许OPTIONS请求 .requestMatchers("/api/public/**").permitAll .anyRequest.authenticated)Spring Boot3 基于 Spring Framework 6，在 CORS 处理上有部分细节优化，同时也存在一些与旧版本不兼容的地方，开发者在升级或新建项目时需特别注意。
（一）Spring Boot3 的 CORS 优化点
支持通配符域名配置：在 Spring Boot3 中，allowedOrigins 支持更灵活的通配符配置，例如 allowedOrigins("https://*.example.com")，可允许同一主域名下的所有子域名跨域（如 https://a.example.com、https://b.example.com），无需逐一指定子域名，减少配置冗余。
预检请求缓存默认值调整：Spring Boot3 中，maxAge（预检请求缓存时间）的默认值从原来的 1800 秒（30 分钟）调整为 86400 秒（24 小时），减少频繁的预检请求，提升跨域请求效率。若需修改，可在 addCorsMappings 中手动指定 maxAge 值。
与 Jakarta Servlet API 的兼容性：Spring Boot3 全面迁移到 Jakarta Servlet API（从 javax.servlet 改为 jakarta.servlet），因此自定义 CORS 过滤器时，需导入 jakarta.servlet.Filter 接口，而非旧的 javax.servlet.Filter。若使用旧的导入路径，会导致过滤器无法加载，出现 ClassNotFoundException 错误。
示例：Spring Boot3 中正确的过滤器导入：
// 正确：使用Jakarta Servlet APIimport jakarta.Servlet.Filter;import jakarta.servlet.FilterChain;import jakarta.servlet.ServletRequest;import jakarta.servlet.ServletResponse;import jakarta.servlet.http.HttpServletResponse;// 错误：旧的javax.servlet API（Spring Boot3中已不支持）// import javax.servlet.Filter;// import javax.servlet.FilterChain;（二）常见配置误区与避坑指南
allowCredentials=true 与 allowedOrigins="*" 冲突：当 allowCredentials 设置为 true（允许前端携带 Cookie 或令牌）时，allowedOrigins 不能使用 *（通配符），否则浏览器会拒绝跨域响应 —— 因为 * 表示允许所有来源，而携带凭证的跨域请求需要明确指定来源，避免安全风险。若需允许多个来源且携带凭证，需通过 allowedOrigins 逐一指定，或通过动态判断请求的 Origin 是否在白名单中，再设置 Access-Control-Allow-Origin 响应头。
动态配置示例：
public class DynamicCorsFilter implements Filter { // 跨域白名单 private static final ListALLOWED_ORIGINS = Arrays.asList( "https://www.frontend1.com", "https://www.frontend2.com" ); @Override public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) res; // 获取请求来源 String origin = request.getHeader("Origin"); // 若来源在白名单中，设置允许跨域 if (ALLOWED_ORIGINS.contains(origin)) { response.setHeader("Access-Control-Allow-Origin", origin); response.setHeader("Access-Control-Allow-Credentials", "true"); response.setHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE"); response.setHeader("Access-Control-Allow-Headers", "Content-Type, Authorization"); } chain.doFilter(req, res); }}重复配置导致冲突：若项目中同时使用 @CrossOrigin 注解和全局 CORS 配置，会导致配置冲突 ——@CrossOrigin 注解的优先级高于全局配置，即某个 Controller 方法若添加了 @CrossOrigin，会覆盖全局配置。若需统一管理跨域规则，建议删除所有 @CrossOrigin 注解，仅保留全局配置，避免规则混乱。
忽略静态资源的跨域配置：若前端需要加载后端的静态资源（如图片、文件），需确保 CORS 配置覆盖静态资源路径。例如，若静态资源放在 /static 目录下，需在全局配置中设置 addMapping("/**")（覆盖所有路径），或明确指定 addMapping("/static/**")，避免静态资源请求被跨域拦截。
在 Spring Boot3 项目中，不存在 “绝对最优” 的跨域解决方案，需根据项目场景（开发 / 生产、简单 / 复杂架构）、安全性要求和团队技术栈，选择最适合的方案。以下是不同场景下的选择建议：
项目场景推荐解决方案优势注意事项开发环境调试全局 CORS 配置（WebMvcConfigurer）配置简单，覆盖所有接口，适合快速调试避免使用 allowedOrigins="*" 搭配 allowCredentials=true生产环境（简单架构）全局 CORS 配置 + Nginx 反向代理兼顾安全性和性能，减少跨域请求损耗严格指定 allowedOrigins，仅开放必需的方法和请求头生产环境（复杂架构）自定义 CORS 过滤器支持动态白名单、多环境适配，灵活性高确保过滤器执行顺序在业务过滤器之前整合 Spring Security自定义 CORS 过滤器 + Security 过滤链兼容身份验证逻辑，避免 CORS 被 Security 拦截允许 OPTIONS 请求匿名访问，关闭默认 CORS 配置仅需单个接口跨域@CrossOrigin 注解无需全局配置，针对性强不建议在多接口场景使用，避免规则混乱跨域问题的核心是 “平衡安全性与灵活性”—— 既要在满足业务灵活性的同时，守住安全底线。无论是选择哪种解决方案，都需牢记 “最小权限” 原则 —— 仅开放必需的跨域来源、方法和请求头，避免因过度开放导致安全漏洞。
很多开发者对同源策略的理解停留在 “协议、域名、端口一致” 的表层，却忽略了其背后的安全设计逻辑 —— 同源策略本质是浏览器对 “资源访问权限” 的隔离机制，防止恶意网站通过 “跨域请求” 窃取用户在其他网站的敏感数据（如 Cookie、LocalStorage 中的登录态）。
需要明确的是，同源策略并非 “一刀切” 的拦截，而是存在明确的边界：
允许跨域加载资源，但限制跨域读取资源：浏览器允许从不同源加载图片、脚本、样式等静态资源（如），但禁止通过 JavaScript 读取这些资源的内容（如获取图片的像素数据）。简单请求与非简单请求的差异化处理：浏览器将跨域请求分为两类，简单请求（如 GET、POST 方法，且请求头仅包含 Accept、Content-Type 等少数安全头）可直接发送，无需预检；非简单请求（如 PUT/DELETE 方法、包含自定义请求头）则需先发送 OPTIONS 预检请求，确认服务器允许后再发送实际请求。这种差异化处理既保障了安全，又减少了简单场景下的性能损耗。
理解这些边界，能帮助开发者在遇到 “特殊跨域场景” 时快速判断问题本质。例如，当使用
来源：从程序员到架构师
