CORS需服务器配合实现，核心是浏览器拦截跨域请求后由服务端响应头“开绿灯”；同源策略要求协议、域名、端口全一致，否则静默拦截；简单请求直接发送，复杂请求先发OPTIONS预检；关键响应头包括Access-Control-Allow-Origin、Methods、Headers及Credentials（带凭证时Origin不能为*）。
JavaScript 中的跨域请求本身不能“主动实现”，而是靠服务器配合才能成功——CORS 的核心逻辑是：浏览器拦住跨域请求，但允许服务器用响应头“开绿灯”。只要后端正确设置几个关键响应头，前端发请求时几乎不用改代码。
浏览器为什么拦你？同源策略是默认守门员
协议、域名、端口三者完全一致才算同源。比如 https://a.com 页面去请求 https://b.com/api，哪怕只差一个字母或端口（如 8080），浏览器就直接拒绝响应数据——不是报错，是“静默拦截”：请求发出去了、服务器也返回了，但 JavaScript 拿不到 response.body，控制台只显示 CORS 错误。
CORS 分两种情况：简单请求不预检，复杂请求先问再干
浏览器自动判断：
- 简单请求：方法是 GET/HEAD/POST，且 Header 只含 Accept、Content-Type（限于 application/x-www-form-urlencoded、multipart/form-data、text/plain）等基础字段。这类请求会直接发，只多加一个 Origin 请求头。
- 非简单请求：比如带自定义头（X-Auth-Token）、用 PUT/DELETE 方法、Content-Type 是 application/json —— 浏览器会先发一个 OPTIONS 预检请求，询问服务器：“我待会要用 POST 带 X-Token 访问，你允不允许？” 服务器必须在预检响应里明确答复，否则后续请求根本不发。
服务器必须设置的关键响应头
这些头不是可选的，是浏览器校验的硬性条件：
立即学习“Java免费学习笔记（深入）”；
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- Access-Control-Allow-Origin：必须有。值可以是具体域名（https://your-app.com）或通配符 *（但带凭证时不能用 *）。
- Access-Control-Allow-Methods：预检响应中必需，列出允许的方法，如 GET, POST, PUT。
- Access-Control-Allow-Headers：预检响应中必需，声明允许携带哪些请求头，如 Content-Type, X-Auth-Token。
- Access-Control-Allow-Credentials：如果前端设了 credentials: 'include'（要传 cookie 或 auth），此项必须为 true，且 Allow-Origin 不能是 *。
前端代码其实很安静，重点在后端配置
你写 fetch 或 axios，和同域请求一模一样：
fetch('https://api.example.com/data', {
method: 'POST',
headers: {'Content-Type': 'application/json'},
credentials: 'include' // 如果需要带 cookie
})
真正起作用的是后端是否返回了合法的 CORS 头。Node.js Express 示例：
app.use((req, res, next) => {
res.header('Access-Control-Allow-Origin', 'https://your-app.com');
res.header('Access-Control-Allow-Credentials', 'true');
res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
res.header('Access-Control-Allow-Headers', 'Content-Type, X-Auth-Token');
if (req.method === 'OPTIONS') return res.sendStatus(200);
next();
});
基本上就这些。CORS 不复杂，但容易忽略预检流程或 credentials 与 * 的冲突。
