"前端小哥又双叒喊我联调了，浏览器疯狂报CORS错误？"
"明明Postman能调通，浏览器死活拦请求？"
"加了@CrossOrigin注解，带Cookie的请求还是被拒？"

如果你也曾在Spring Boot跨域问题上反复踩坑，这篇文章将用最硬核的解决方案+底层原理解析，一次性扫清所有障碍！文末附自测Checklist和常见作死操作，建议收藏！

一、先搞懂本质：为什么浏览器要拦你？

跨域问题本质是浏览器的安全策略（同源策略），与服务端无关！

• 核心矛盾：当前端域名（如http://localhost:3000）与后端API域名（如http://localhost:8080）不同源时，浏览器会拦截响应
• 关键响应头：
• 复制
• 下载
• Access-Control-Allow-Origin: 允许的源 Access-Control-Allow-Methods: 允许的HTTP方法 Access-Control-Allow-Headers: 允许的请求头 Access-Control-Allow-Credentials: 是否允许携带凭证

记住：服务端只需正确设置这些响应头，浏览器就会放行！

二、Spring Boot解决跨域的3种方案（附代码+避坑指南）

方案1：全局配置（推荐生产环境使用）

适用场景：统一管理所有接口的CORS规则

java

@Configuration  
public class CorsConfig implements WebMvcConfigurer {  
    @Override  
    public void addCorsMappings(CorsRegistry registry) {  
        registry.addMapping("/**")  
                .allowedOrigins("http://localhost:3000", "https://your-prod-domain.com")  
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")  
                .allowedHeaders("*")  
                .allowCredentials(true)  
                .maxAge(3600);  
    }  
}  

避坑指南：

• 若启用allowCredentials(true)，allowedOrigins不能为通配符*，必须明确指定域名！
• maxAge设置预检请求缓存时间，减少OPTIONS请求次数

方案2：注解驱动（灵活但易遗漏）

适用场景：为特定Controller或方法单独配置

java

@RestController  
@CrossOrigin(origins = "http://localhost:3000", allowCredentials = "true")  
public class UserController {  

    @GetMapping("/user")  
    @CrossOrigin(maxAge = 1800) // 可覆盖类级别配置  
    public User getUser() {  
        // ...  
    }  
}  

致命坑点：

• 类和方法同时使用@CrossOrigin时，属性会合并而非覆盖（如methods取并集）
• 若全局配置和注解共存，注解优先级更高

方案3：Spring Security整合（最易翻车）

适用场景：项目已集成Spring Security

java

@Configuration  
@EnableWebSecurity  
public class SecurityConfig extends WebSecurityConfigurerAdapter {  

    @Override  
    protected void configure(HttpSecurity http) throws Exception {  
        http.cors() // 启用CORS配置  
            .and()  
            .csrf().disable(); // 根据业务决定是否关闭CSRF  
    }  

    @Bean  
    CorsConfigurationSource corsConfigurationSource() {  
        CorsConfiguration configuration = new CorsConfiguration();  
        configuration.setAllowedOrigins(Arrays.asList("http://localhost:3000"));  
        configuration.setAllowedMethods(Arrays.asList("*"));  
        configuration.setAllowedHeaders(Arrays.asList("*"));  
        configuration.setAllowCredentials(true);  
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();  
        source.registerCorsConfiguration("/**", configuration);  
        return source;  
    }  
}  

血泪教训：

• 必须同时启用.cors()和定义CorsConfigurationSource Bean
• 如果保留CSRF保护，需配合withCsrfToken处理（进阶话题）

三、高频深坑：这些错误操作你中招了吗？

1. 陷阱：Nginx配置了CORS，后端又配一次导致冲突

现象：响应头中出现重复的
Access-Control-Allow-Origin
解决方案：保持单一配置层，不要重复设置！

2. 陷阱：用了通配符*还开allowCredentials

后果：浏览器直接拒绝请求！
修正：

java

// 错误写法  
.allowedOrigins("*")  
.allowCredentials(true)  

// 正确写法  
.allowedOrigins("http://your-specific-domain.com")  
.allowCredentials(true)  

3. 陷阱：忘记处理OPTIONS预检请求

现象：POST请求被拦截，控制台提示缺少CORS头
真相：复杂请求（如Content-Type=application/json）会先发OPTIONS请求探路
应对：确保Spring Boot正确处理OPTIONS方法（全局配置已包含）

4. 陷阱：Vue等前端框架的代理配置混淆

典型错误：开发环境同时配了前端代理和后端CORS，导致逻辑混乱
最佳实践：

• 开发环境：前端配置代理（如vue.config.js的devServer.proxy）
• 生产环境：后端配置CORS

四、自测Checklist：你的跨域配置真的生效了吗？

1. 打开浏览器开发者工具 → Network选项卡
2. 查看响应头是否包含Access-Control-Allow-Origin
3. 携带Cookie的请求检查Access-Control-Allow-Credentials: true
4. 复杂请求观察是否有OPTIONS预检请求，并返回204状态码

结语

跨域问题本质是前后端协作的信任机制——浏览器要保护用户，而开发者要明确告诉浏览器：“这个API可信！”。点赞收藏本文，下次遇到CORS问题时，你定能快速定位，一剑封喉！