从‘Access to XMLHttpRequest... blocked by CORS policy’错误出发：深入理解浏览器同源策略与CORS机制

1. 为什么浏览器会阻止跨域请求？

第一次遇到CORS错误时，我和大多数开发者一样感到困惑。明明后端接口已经正常返回了数据，为什么浏览器还是报错？这个问题得从浏览器的安全基石——同源策略说起。

同源策略就像小区的门禁系统。假设你住在A小区，想要进入B小区的健身房。门卫会检查你的身份：是否属于本小区业主？是否有访客预约？这种检查虽然麻烦，但能防止陌生人随意进出。浏览器对跨域请求的限制也是类似的逻辑，它要确认"这个请求是否来自可信的源"。

具体来说，同源策略要求比较三个要素：

• 协议：就像小区不同的出入口（人行门、车行门），http和https被视为不同源
• 域名：主域名和子域名都算不同源，比如api.example.com和www.example.com
• 端口：即使是同一个服务，80端口和8080端口也被视为不同源

我曾在项目中踩过这样的坑：前端页面用https运行，但接口地址配置成了http。虽然开发环境能正常工作，上线后却出现CORS错误。这就是因为协议不同导致不同源，浏览器拦截了请求。

2. CORS如何架起跨域桥梁？

2.1 CORS的工作原理

CORS机制就像国际快递的清关流程。当你从海外购买商品时：

1. 海关会检查包裹内容（浏览器检查请求头）
2. 需要提供通关文件（服务器返回CORS头）
3. 符合条件才放行（浏览器允许获取响应）

一个真实的请求流程是这样的：

javascript复制// 前端代码
fetch('https://api.example.com/data', {
  method: 'GET',
  headers: {
    'Content-Type': 'application/json'
  }
})

浏览器会自动添加Origin头：

code复制GET /data HTTP/1.1
Origin: https://your-site.com
Host: api.example.com

服务器需要响应这些头信息：

code复制Access-Control-Allow-Origin: https://your-site.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type

2.2 预检请求的奥秘

非简单请求会触发预检（preflight），这就像重要访客需要提前登记。我曾在项目中使用自定义头X-Auth-Token，结果发现每次请求都会先发OPTIONS请求。

预检请求示例：

code复制OPTIONS /resource HTTP/1.1
Origin: https://your-site.com
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: X-Auth-Token

服务器必须明确允许这些操作：

code复制Access-Control-Allow-Origin: https://your-site.com
Access-Control-Allow-Methods: GET, POST, DELETE
Access-Control-Allow-Headers: X-Auth-Token
Access-Control-Max-Age: 86400  // 缓存1天

3. 常见CORS解决方案实战

3.1 后端配置方案

在Spring Boot中，我推荐使用WebMvcConfigurer统一配置：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOrigins("https://your-domain.com") 
                .allowedMethods("*")
                .allowedHeaders("*")
                .exposedHeaders("X-Custom-Header")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

注意几个易错点：

• allowCredentials(true)时不能使用allowedOrigins("*")
• 生产环境应该明确指定域名而非通配符
• 网关层也需要配置CORS，避免多层拦截

3.2 Nginx反向代理方案

这是我最推荐的零侵入方案，配置示例：

nginx复制server {
    listen 80;
    server_name api.your-domain.com;
    
    location / {
        proxy_pass http://backend-service;
        
        # 处理预检请求
        if ($request_method = OPTIONS) {
            add_header Access-Control-Allow-Origin "$http_origin";
            add_header Access-Control-Allow-Methods "GET, POST, OPTIONS";
            add_header Access-Control-Allow-Headers "Authorization, Content-Type";
            add_header Access-Control-Allow-Credentials "true";
            add_header Content-Length 0;
            add_header Content-Type text/plain;
            return 204;
        }
        
        add_header Access-Control-Allow-Origin "$http_origin";
        add_header Access-Control-Allow-Credentials "true";
        add_header Access-Control-Expose-Headers "X-Custom-Header";
    }
}

4. 深度理解CORS安全机制

4.1 凭证与安全限制

当涉及Cookie和认证时，CORS有严格限制。我在电商项目中就遇到过这样的场景：用户登录态需要跨子域共享。

正确做法是：

1. 前端设置withCredentials

javascript复制fetch('https://api.example.com/auth', {
  credentials: 'include'
})

2. 服务端响应头必须包含：

code复制Access-Control-Allow-Origin: https://shop.example.com
Access-Control-Allow-Credentials: true
Set-Cookie: token=xxx; Domain=.example.com; Secure; SameSite=None

4.2 现代浏览器的安全演进

随着安全要求提高，Chrome 80+版本对Cookie策略做了重大调整：

• 默认SameSite=Lax，会阻止跨站Cookie
• 需要显式设置SameSite=None; Secure才能跨域传输
• 不安全的域名（非https）无法设置SameSite=None

这导致很多历史项目突然出现跨域问题。我的解决经验是：

1. 全站升级HTTPS
2. 明确设置Cookie属性
3. 测试不同浏览器版本的表现差异