CORS是浏览器强制实施的跨域安全机制，非可选方案；其核心判断依据是响应头中Access-Control-Allow-Origin是否精确匹配请求源，且与credentials=true互斥，预检请求需服务端正确响应OPTIONS。
CORS 不是“替代”跨域请求的方案，它本身就是浏览器处理跨域请求时必须依赖的机制。没有 CORS，现代浏览器根本不会放行前端发起的跨域 fetch 或 XMLHttpRequest 请求——哪怕服务端返回了 200 状态码，前端 JS 也拿不到响应体。
为什么浏览器报错但 Network 里能看到 200 响应？
这是最典型的 CORS 失败表象：控制台报 Access to fetch at 'http://api.example.com/data' from origin 'http://localhost:3000' has been blocked by CORS policy，但 Network 面板里该请求状态码是 200，Response 标签页甚至能点开看到完整数据。
原因很直接：浏览器确实发出了请求、服务端也正常响应了，但**响应头里缺关键字段**，导致浏览器在 JS 层面主动拦截了响应内容，不交给你的 fetch().then() 或 xhr.onload 处理。
关键判断点只有一条：Access-Control-Allow-Origin 是否存在且匹配当前页面的 Origin（协议+域名+端口）。其他字段如 Access-Control-Allow-Methods、Access-Control-Allow-Headers 只在预检请求（OPTIONS）阶段起作用。
立即学习“前端免费学习笔记（深入）”；
- 如果服务端返回
Access-Control-Allow-Origin: *，且你没带凭证（如 cookies、Authorization header），那通常能过 - 如果带了
credentials: true或withCredentials = true，则Access-Control-Allow-Origin**不能是***，必须精确匹配，比如http://localhost:3000 - 如果请求含自定义 header（如
X-Request-ID）或用PUT/DELETE方法，浏览器会先发一次 OPTIONS 预检；此时服务端必须对 OPTIONS 请求返回 204 或 200，并带上所有允许字段，否则连实际请求都不会发
Access-Control-Allow-Origin 设置为 * 就万事大吉？
不是。设成 * 是最快捷的开发期写法，但它和 credentials 天然互斥。
一旦你在前端代码里写了：
fetch('http://api.example.com/login', {
credentials: 'include'
})而服务端响应头是：
Access-Control-Allow-Origin: * Access-Control-Allow-Credentials: true
浏览器会直接拒绝——这不是 bug，是规范强制要求。W3C 明确规定：当 Access-Control-Allow-Credentials: true 时，Access-Control-Allow-Origin 必须是具体源，不能是通配符。
所以真实部署时，后端得根据请求头里的 Origin 动态回写，例如：
- 收到
Origin: http://app.company.com→ 回Access-Control-Allow-Origin: http://app.company.com - 收到
Origin: http://staging.company.com→ 回Access-Control-Allow-Origin: http://staging.company.com - 收到非法或空
Origin→ 不回该 header，或回一个默认白名单里的源
硬编码成 * 的后果：登录态（cookies）、token 自动携带失败，用户始终无法保持会话。
前端能不能绕过 CORS？
不能。CORS 是浏览器实现的防护层，不是网络层限制。你用 curl、Postman、甚至后端代码发请求，完全不受影响——它们压根不检查 CORS header。
常见误解：
-
location.href跳转、<img src="">、<script src="">这些能“跨域加载”，是因为它们不触发 CORS 检查，但你也**拿不到响应内容**（比如图片的像素数据、脚本的执行上下文） - 改 Chrome 启动参数加
--disable-web-security只能用于本地调试，生产环境无效，且新版 Chrome 已基本禁用该方式 - 前端用
postMessage或iframe通信，本质是同源页面间协作，不解决“前端直连跨域 API”的问题
真正可行的“绕过”只有服务端中转：让前端请求自己同源的接口（如 /api/proxy/user），由这个接口去调第三方服务，再把结果返回。但这已不属于 CORS 范畴，而是架构层面的代理策略。
CORS 的核心复杂点从来不在“怎么配”，而在于动态源匹配 + credentials 共存 + 预检缓存这三者的组合逻辑。很多线上问题不是漏写了 header，而是 OPTIONS 响应没缓存、或者 Vary: Origin 缺失导致 CDN 缓存污染。这些细节不暴露在控制台错误里，但会让跨域在部分用户身上间歇性失效。
