深入解析CORS预检请求：为什么前端不该手动设置跨域头

最近在技术社区看到一个高频问题：为什么明明按照教程配置了Access-Control-Allow-Origin头，跨域请求还是会失败？更奇怪的是，删除前端代码中的相关设置后反而成功了。这背后其实隐藏着浏览器安全机制与HTTP协议的精妙设计。

1. CORS的本质与浏览器安全策略

跨域资源共享(CORS)是现代浏览器实现的一种安全机制，它的核心目的是在开放Web能力的同时保护用户数据安全。想象一下，如果没有这种限制，任意网站都能随意读取你的银行会话cookie会是多么危险。

关键点在于区分简单请求与非简单请求：

• 简单请求需同时满足：

  • 方法为GET/HEAD/POST
  • 仅包含安全头部（如Accept、Content-Language）
  • Content-Type为text/plain、multipart/form-data或application/x-www-form-urlencoded

• 非简单请求会触发预检(Preflight)流程：

  • 浏览器先发送OPTIONS请求询问服务器是否允许
  • 服务器返回允许的方法和头部列表
  • 浏览器验证通过后才发送真实请求

常见误区：认为所有跨域请求都会发送预检。实际上只有非简单请求才会触发这个机制。

2. 为什么前端设置CORS头是错误做法

原始案例中开发者在前端ajax请求里添加了：

javascript复制beforeSend: function(xhr) {
    xhr.setRequestHeader("Access-Control-Allow-Origin", "*"); 
}

这实际上违反了HTTP协议的基本规则：

根本原因：

• Access-Control-Allow-Origin是服务器告诉浏览器"我允许哪些来源访问"的响应头
• 客户端设置这个头就像在信封上自己盖"已检"章一样无效且误导系统

3. Spring Boot中的正确配置方式

3.1 注解式配置

最简洁的方式是使用@CrossOrigin注解：

java复制@RestController
@RequestMapping("/api")
public class MyController {
    
    @CrossOrigin(origins = "*")
    @PostMapping("/data")
    public ResponseEntity<String> createData() {
        return ResponseEntity.ok("Success");
    }
}

3.2 全局配置

对于需要统一规则的项目，推荐实现WebMvcConfigurer：

java复制@Configuration
public class WebConfig implements WebMvcConfigurer {
    
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOrigins("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE")
                .allowedHeaders("*")
                .maxAge(3600);
    }
}

3.3 过滤器方案

某些特殊场景可能需要更精细控制：

java复制@Bean
public FilterRegistrationBean<CorsFilter> corsFilter() {
    UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
    CorsConfiguration config = new CorsConfiguration();
    config.setAllowCredentials(true);
    config.addAllowedOrigin("https://trusted-domain.com");
    config.addAllowedHeader("*");
    config.addAllowedMethod("*");
    source.registerCorsConfiguration("/**", config);
    return new FilterRegistrationBean<>(new CorsFilter(source));
}

4. 预检请求的深度解析

当遇到预检请求失败时，建议按以下流程排查：

1. 确认请求类型：

   • 检查是否使用了非简单方法（PUT/DELETE等）
   • 检查是否包含自定义头部

2. 抓包分析：

   bash复制# 使用curl模拟预检请求
   curl -X OPTIONS http://api.example.com/resource \
     -H "Access-Control-Request-Method: POST" \
     -H "Access-Control-Request-Headers: X-Custom-Header" \
     -H "Origin: http://client.example.com"
   

3. 响应头验证：

   • 确保OPTIONS响应包含：
     • Access-Control-Allow-Origin
     • Access-Control-Allow-Methods
     • Access-Control-Allow-Headers（如有自定义头）

4. 缓存控制：

   • 合理设置Access-Control-Max-Age减少预检次数

5. 常见陷阱与最佳实践

高频踩坑点：

• 忘记处理OPTIONS方法（Spring Boot自动处理）
• 多个CORS配置冲突（注解+全局配置混用）
• 带凭证的请求使用通配符origin（需明确指定）
• 网关层（如Nginx）重复设置CORS头

性能优化建议：

• 对稳定API设置较长的max-age
• 避免使用通配符头部，明确列出所需头部
• 对简单请求避免不必要的预检

在微服务架构中，更推荐在API网关统一处理CORS，而不是在每个服务重复配置。比如使用Spring Cloud Gateway的配置：

yaml复制spring:
  cloud:
    gateway:
      globalcors:
        cors-configurations:
          '[/**]':
            allowedOrigins: "https://portal.example.com"
            allowedMethods: "*"
            allowedHeaders: "*"
            exposedHeaders: "X-Custom-Header"
            maxAge: 1800

理解CORS机制不仅能解决眼前的问题，更能帮助开发者设计出更安全的Web架构。记住关键原则：让专业的组件做专业的事，浏览器负责安全策略，服务器声明访问规则，而客户端应该保持"无知"——这正是现代Web安全模型的精妙之处。