你有没有遇到过这种情况：在自己的网页上想请求别人的API，结果浏览器直接报错：
Access-Control-Allow-Origin' header is missing。为什么浏览器要阻止你？服务器不响应不就完了吗？
今天，用小区门禁的故事，来讲讲 跨域 与 CORS。
原文地址
墨渊书肆/为什么禁止我请求别的网站的接口？——跨域与CORS
什么是"跨域"？
同源策略 — 浏览器的安全基石
浏览器有个同源策略（Same-Origin Policy）：只有来自同一个"家"的资源才能随便用。
什么叫"同一个家"？看三个条件：协议（http/https）、域名（example.com）、端口（:8080）。三个都一样，才是同源；有一个不一样，就是跨域。
跨域的例子
✅ http://example.com 和 http://example.com/profile // 协议+域名+端口都相同 → 同源
✅ https://example.com 和 https://example.com // 协议+域名+端口都相同 → 同源
❌ http://example.com 和 https://example.com // 协议不同 → 跨域
❌ http://example.com 和 http://api.example.com // 域名不同（子域名）→ 跨域
❌ http://example.com:8080 和 http://example.com:3000 // 端口不同 → 跨域
跨域限制了什么？
浏览器的同源策略主要限制了三件事：
- DOM 访问：无法读取不同源的 iframe 内容、无法修改不同源的 iframe DOM
- AJAX 请求：无法请求不同源的 API
- Cookie/LocalStorage：无法访问不同源的数据
为什么要限制跨域？
模拟一个攻击场景
想象一下：你登录了银行网站 bank.com，浏览器保存了你的登录 Cookie。
然后你手滑点进了一个恶意网站 evil.com，这个网站里有一段代码：
<form action="http://bank.com/transfer" method="POST">
<input type="hidden" name="to" value="hacker">
<input type="hidden" name="amount" value="1000000">
</form>
<script>document.forms[0].submit();</script>
如果没有同源策略，这个表单请求会自动带上 bank.com 的 Cookie，银行服务器以为是你本人操作的——钱就没了。
同源策略就是浏览器的"门禁"：只有同一家人才能进，陌生人要查证件。
💡 注意：
<img>标签的 GET 请求虽然也会带 Cookie，但现代浏览器有SameSiteCookie 保护。上面表单 POST 场景更典型。
CORS — 跨域的"通行证"
CORS 是什么？
CORS（Cross-Origin Resource Sharing）= 跨域资源共享。
它的工作原理很简单：让服务器告诉浏览器，"我允许来自这些源的请求"。
简单请求 vs 预检请求
简单请求
满足以下条件的请求是"简单请求"：
| 条件 | 要求 |
|---|---|
| 请求方法 | GET、POST 或 HEAD |
| 请求头部 | 只有几种常见类型 |
| Content-Type | 只能是 application/x-www-form-urlencoded、multipart/form-data 或 text/plain |
简单请求的流程：
1. 浏览器发送请求（自动带上 Origin 头）
↓
2. 服务器检查 Origin，决定是否允许
↓
3. 服务器返回响应头 Access-Control-Allow-Origin
↓
4. 浏览器检查响应头，允许就完事
服务器端示例（Node.js）：
app.get('/api/data', (req, res) => {
const origin = req.headers.origin;
if (origin === 'https://example.com') {
res.setHeader('Access-Control-Allow-Origin', origin);
}
res.json({ data: '这是返回的数据' });
});
响应头：
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.com
Content-Type: application/json
{"data": "这是返回的数据"}
预检请求（Preflight）
不满足"简单请求"条件的，浏览器会先发一个 OPTIONS 请求"探路"：
1. 浏览器发送 OPTIONS 预检请求
↓
2. 服务器检查方法/头部/Origin
↓
3. 服务器返回允许的头 Access-Control-*
↓
4. 浏览器发送实际请求
预检请求检查什么？
预检请求（OPTIONS）就像登机前的安检——先检查你带没带危险品。
浏览器会问服务器三件事：
- 我从哪来？（Origin）
- 我想用什么方法？（Access-Control-Request-Method）
- 我想带什么头？（Access-Control-Request-Headers）
服务器回答"可以"，浏览器才放行实际请求。
# 请求（浏览器发给服务器）
OPTIONS /api/data HTTP/1.1
Origin: https://example.com # 我从哪来
Access-Control-Request-Method: PUT # 我想用 PUT 方法
Access-Control-Request-Headers: Content-Type, Authorization # 我想带这些头
---
# 响应（服务器告诉浏览器）
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://example.com # 允许这个源
Access-Control-Allow-Methods: GET, POST, PUT, DELETE # 允许这些方法
Access-Control-Allow-Headers: Content-Type, Authorization # 允许这些头
Access-Control-Max-Age: 86400 # 预检结果缓存24小时
服务器端处理：
app.options('/api/data', (req, res) => {
const origin = req.headers.origin;
if (origin === 'https://example.com') {
res.setHeader('Access-Control-Allow-Origin', origin);
res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE');
res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
res.setHeader('Access-Control-Max-Age', '86400');
}
res.status(204).send();
});
CORS 响应头详解
常用响应头
| 响应头 | 作用 | 例子 |
|---|---|---|
Access-Control-Allow-Origin | 允许的源 | * 或 https://example.com |
Access-Control-Allow-Methods | 允许的方法 | GET, POST, PUT |
Access-Control-Allow-Headers | 允许的头部 | Content-Type, Authorization |
Access-Control-Max-Age | 预检缓存时间 | 86400（秒） |
Access-Control-Allow-Credentials | 是否允许带 Cookie | true |
credentials 模式
默认情况下，CORS 不带 Cookie。如果需要携带 Cookie：
前端：
fetch('/api/data', {
credentials: 'include'
});
服务端：
res.setHeader('Access-Control-Allow-Origin', 'https://example.com');
res.setHeader('Access-Control-Allow-Credentials', 'true');
注意：Access-Control-Allow-Origin 不能用 *，必须是具体域名。
跨域的解决方案
1. JSONP（已不推荐）
利用 <script> 标签不受同源策略限制的特性：
<script>
function handleData(data) {
console.log(data);
}
</script>
<script src="http://api.example.com/data?callback=handleData"></script>
| 缺点 | 说明 |
|---|---|
| 只支持 GET | 无法处理 POST 等请求 |
| 有安全风险 | 可能被注入恶意代码 |
| 无法捕获错误 | 错误处理困难 |
2. 代理服务器
在自己的服务器上转发请求，"伪装"成同源：
浏览器 ──> 我的服务器（同一源） ──> 目标服务器
Nginx 代理：
location /api/ {
proxy_pass http://target-server.com/;
}
Node.js 代理：
app.get('/api/data', async (req, res) => {
const response = await fetch('http://target-server.com/data');
const data = await response.json();
res.json(data);
});
3. Webpack/Vite 开发代理
开发环境配置代理：
// vite.config.js
export default {
server: {
proxy: {
'/api': {
target: 'http://target-server.com',
changeOrigin: true
}
}
}
};
4. postMessage
不同窗口/iframe 之间的通信：
window.addEventListener('message', (event) => {
if (event.origin === 'https://example.com') {
console.log('收到消息:', event.data);
}
});
iframe.contentWindow.postMessage('hello', 'https://example.com');
深入了解 CORS 🔬
第三方 Cookie 的限制
现代浏览器正在逐步限制第三方 Cookie：
| 浏览器 | 政策 |
|---|---|
| Chrome | 计划逐步淘汰第三方 Cookie |
| Safari | 默认阻止第三方 Cookie |
| Firefox | 提供第三方 Cookie 阻止选项 |
CORS 和 CSRF 的区别
| CORS | CSRF | |
|---|---|---|
| 是什么 | 跨域资源共享机制 | 跨站请求伪造攻击 |
| 作用 | 服务端允许/禁止跨域请求 | 利用用户已登录状态发起攻击 |
| 防御 | 服务端配置 Access-Control-* | Token、SameSite Cookie、验证码 |
为什么 OPTIONS 叫"预检"？
"预检"就像登机前的安检——先检查你带没带危险品（方法、头部），没问题了才让你登机（发送实际请求）。
常见错误排查
错误 1：No 'Access-Control-Allow-Origin' header
| 原因 | 解决 |
|---|---|
| 服务端没配置 CORS | 添加 Access-Control-Allow-Origin 头 |
| Origin 不匹配 | 检查配置的域名是否正确 |
credentials 时用了 * | 必须指定具体域名 |
错误 2：Method not allowed
| 原因 | 解决 |
|---|---|
请求方法（如 PUT）不在允许列表 | 检查 Access-Control-Allow-Methods |
错误 3：Header not allowed
| 原因 | 解决 |
|---|---|
请求头部（如 Authorization）不在允许列表 | 检查 Access-Control-Allow-Headers |
错误 4：预检请求 404
| 原因 | 解决 |
|---|---|
| 服务端没有处理 OPTIONS 请求 | 中间件或网关要放行 OPTIONS |
总结
| 概念 | 像什么 | 作用 |
|---|---|---|
| 同源策略 | 小区门禁 | 限制不同源的访问，保护安全 |
| CORS | 通行证 | 告诉浏览器哪些跨域请求是允许的 |
| 简单请求 | 普通访客 | 不需要预检，直接请求 |
| 预检请求 | 安检验票 | 先检查再放行，更安全的请求 |
| JSONP | 走后门 | 已不推荐，有安全风险 |
| 代理 | 同一个家门 | 绕过跨域，最推荐的开发方案 |
写在最后
现在你应该明白了：
- 跨域是浏览器的安全机制，不是为了刁难你
- CORS 是服务器授权机制，服务器说可以，浏览器才放行
- 预检请求 = 安检，OPTIONS 通过了才能发送实际请求
- 生产环境推荐用代理，开发环境用 webpack/vite 代理
下次遇到跨域错误，先看浏览器控制台的报错信息——是"缺通行证"（header 缺失）还是"通行证不对"（origin 不匹配），处理方式不一样的。
