说实话，作为一名在代码堆里摸爬滚打多年的开发者，每次kan到控制台里那行红彤彤的报错信息，心里总还是会“咯噔”一下。尤其是当你刚把接口调通，正准备庆祝一下结果浏览器冷冰冰地扔给你一句：Access to XMLHttpRequest at '...' from origin '...' has been blocked by CORS policy...。这种时候，是不是特别想把键盘砸了？别急，这其实是浏览器在“尽职尽责”地保护用户安全，而我们要Zuo的，就是学会如何跟这位“铁面无私”的守门人打交道。

今天咱们不聊那些虚头巴脑的理论，直接来扒一扒跨域问题的老底，kankan为什么后端在处理这个问题时CORS总是被挂在嘴边，甚至被奉为“关键”所在。

要理解跨域， 得明白什么是“同源”。这可不是说大家来自同一个老家就算同源，在浏览器的逻辑里判定标准严苛得令人发指。它要求两个页面必须同时满足三个核心要素完全一致，缺一不可：

协议

域名

端口

哪怕你的协议和域名dou一模一样，仅仅因为一个是标准的 80 端口，另一个是 8080，对不起，浏览器也会判定你们是“异类”。这里有个小细节值得注意：至于路径、查询参数或者是哈希值，这些dou不影响同源的判定。也就是说http://example.com/api/v1 和 http://example.com/api/v2 是妥妥的同源兄弟。

那为什么要搞这么一套“同源策略”呢？其实这完全是为了安全。想象一下Ru果没有这堵墙，你刚登录了银行网站，Ru果不小心点开了一个恶意网页，这个页面就Neng随意读取你银行页面里的数据，那后果简直不堪设想。所以浏览器出于安全考虑，对同源请求放行，对异源请求限制，这些限制规则统称为同源策略。因为限制造成的开发痛点，就是我们常说的跨域问题。

它主要锁死了三大核心维度，这也是绝大多数跨域问题的根源：

数据存储隔离不同源的站点之间，无法互相读取或写入浏览器端的敏感存储数据，比如 LocalStorageSessionStorage 和 IndexedDB。当然Cookie 的情况稍微特殊一点，虽然原则上也是隔离的，但Ke以通过设置 domain 属性放宽至同根域名下的子域名，不过现在还要受到 SameSite 和 Secure 属性的额外约束，越来越严格了。

DOM 访问隔离不同源的页面之间，无法互相操作 DOM 和 JavaScript 对象。典型的场景就是你用 iframe 嵌入了一个第三方网站，想通过 JS 去获取里面的内容，浏览器会直接拒绝你。

网络请求限制这是咱们今天要聊的重头戏。浏览器默认禁止前端 JS 通过 XMLHttpRequestfetch 等 AJAX 方式，发起跨域请求并读取响应内容。

这里有一个非常经典的误区，hen多刚入行的朋友dou会搞错。大家往往以为，一旦触发了跨域限制，请求就根本没有发出去，或者在后端就被拦截了。

大错特错！

事实的真相是：跨域不是请求发不出去，而是浏览器拦截了响应。请求其实Yi经正常发送到后端，后端也老老实实地处理了逻辑，甚至把响应数据dou准备好了。但是当响应数据回到浏览器这一侧时浏览器发现发起请求的页面和目标地址不符合同源规则，而且响应头里又没有合法的跨域授权标识，于是浏览器就会“翻脸”，阻止 JS 读取响应数据，并在控制台抛出那个让人心烦意乱的跨域错误。

这就好比你寄了一封信出去，收信人收到了并且回了信，结果邮递员在半路上把回信给扣下了理由是“你不该给这个人写信”。你说气人不气人？

既然是浏览器在拦截响应，那怎么让它放行呢？这就轮到 CORS 登场了。全称 Cross-Origin Resource Sharing，翻译过来就是“跨域资源共享”。

简单来说CORS 机制就是让后端在 HTTP 响应头中添加明确的授权标识，告诉浏览器：“嘿，这个跨域请求是被允许的，是我让它发的，你别拦着”。浏览器识别到这些合法的头信息后就会乖乖放行响应数据。

现在的开发模式，比如前后端分离，前端跑在 localhost:8080，后端跑在 localhost:3000，跨域简直是不可避免的。虽然以前也有 JSONP 这种通过 script 标签“钻空子”的方式，或者修改 document.domain 这种土办法，但现在的 Web 标准里CORS 才是正道。

虽然 CORS 是个好东西，但浏览器在处理 CORS 请求时并不是一视同仁的。它把请求分成了两类：简单请求和非简单请求。这两者的处理流程天差地别。

什么样的请求算“简单”？必须同时满足以下两个条件，少一个dou不行：

请求方法仅限于 GETPOSTHEAD 这三种之一。

请求头仅包含以下安全头，不Neng有人自定义的头： * Accept * Accept-Language * Content-Language * Last-Event-ID * Content-Type

流程对于简单请求，浏览器比较“大方”，直接发送请求。后端返回响应时带上 CORS 头，浏览器检查头后决定是否放行响应。整个过程一气呵成，只有一次交互。

不满足上述条件的，统统dou是非简单请求。比如： * 请求方法是 PUTDELETE。 * 带了自定义头，比如 X-Token。 * Content-Type 是 application/json。

流程对于非简单请求，浏览器就变得“小心翼翼”了。它会自动发起一个 OPTIONS 方法的请求，这叫预检请求。

预检请求的作用在发送可Neng修改服务器数据的请求前，先确认后端是否允许，避免对服务器造成意外影响。这就好比你要去别人家里动点贵重物品，得先敲门问问“我Neng不Neng进来弄这个？”，主人说“行”，你才Neng真的进去操作。

既然知道了原理，那后端代码该怎么写呢？咱们以 Go 语言的 Gin 框架为例，写一个中间件来处理这个问题。其实逻辑hen简单，核心就是设置那几个关键的响应头。

func CORS gin.HandlerFunc {
    return func {
        // 1. 允许的源，生产环境千万别写 "*"，要写具体的域名
        c.Writer.Header.Set
        // 2. 允许的请求方法，把常用的dou写上
        c.Writer.Header.Set
        // 3. 允许的请求头，这里hen关键！
        // Ru果前端需要发 Token，必须包含 "Authorization"
        // Ru果前端发 JSON 数据，必须包含 "Content-Type"
        c.Writer.Header.Set
        // 4. 处理 OPTIONS 预检请求
        // 预检请求只需要返回头信息，不需要处理业务逻辑
        if c.Request.Method == "OPTIONS" {
            c.AbortWithStatus // 或者 200 douKe以
            return
        }
        // 5. 放行，继续处理后续逻辑
        c.Next
    }
}

这段代码虽然短，但里面的门道可不少，咱们拆开来kankan。

1. Access-Control-Allow-Origin

这是Zui核心的一个头。它的值决定了哪些源Ke以访问。Ru果是 *，表示谁douNeng访问，这在开发测试阶段倒是无所谓，但上了生产环境，为了安全起见，强烈建议指定具体的域名，比如 https://www.myapp.com。

2. Access-Control-Allow-Methods

告诉浏览器，我这个接口允许哪些方法。Ru果你后端只写了 GET, POST，前端发了个 PUT，预检阶段就会失败。

3. Access-Control-Allow-Headers

这个头是前端开发Zui容易踩坑的地方。它列出了服务器允许携带的请求头字段。

Content-Type前端发 JSON 数据时会自动带这个头，值是 application/json。Ru果不在这里声明允许，后端收不到 JSON 数据，或者预检直接失败。

Authorization前端登录后传 Token 时会带这个头。Ru果不允许，后端拿不到 Token，验证不了身份，接口肯定报错。

代码里有个判断 if c.Request.Method == "OPTIONS"。这是必须的。因为非简单请求会先发预检，Ru果后端不处理 OPTIONS，或者返回 404/405，浏览器就会认为后端不支持跨域，真正的请求根本发不出去。通常我们直接返回 204 状态码即可，表示“我知道了你发吧”。

配置完上面的东西，大部分跨域问题应该douNeng解决了。但在实际项目中，总有一些奇奇怪怪的问题让你抓耳挠腮。

Ru果你的接口需要携带 Cookie，那事情就变得geng复杂了。光设置 Access-Control-Allow-Origin 还不够，还需要满足两个苛刻的条件：

Access-Control-Allow-Origin 不Neng是通配符 *，必须是明确的单一源。

必须增加响应头：Access-Control-Allow-Credentials: true。

同时前端在发起请求时也得显式地设置 withCredentials: true。少了一步，Cookie dou带不过去，登录状态也就丢了。

同源策略虽然严厉，但也不是完全不讲情面。以下场景是不受限制的，大家Ke以放心用：