CORS是浏览器内置的安全机制，用于管控跨源HTTP请求，其核心在于服务器响应头中的Access-Control-Allow-Origin等字段，浏览器据此决定是否将响应交给前端脚本；它源于同源策略，通过简单请求直发或非简单请求预检（OPTIONS）两种方式实现可控跨域。
CORS 是浏览器内置的安全机制，用来管理网页脚本能否从一个源（协议 + 域名 + 端口）向另一个源发起 HTTP 请求。它不是 JavaScript 的功能，也不是后端“不给访问”，而是浏览器主动检查并拦截不被允许的跨源响应。
为什么需要 CORS
浏览器默认执行同源策略：只有协议、域名、端口完全相同，才允许脚本读取响应内容。比如前端运行在 http://localhost:3000，却要请求 https://api.example.com 的数据，这就触发了跨域限制。CORS 提供了一种可控的例外方式——让服务器明确声明“我允许谁来读我的响应”。
CORS 的核心是响应头，不是前端代码
浏览器在发跨域请求时，会自动加一个 Origin 请求头，告诉服务器“我是从哪儿来的”。服务器必须在响应中带上合法的 CORS 头，浏览器才会把响应交给 JavaScript：
-
Access-Control-Allow-Origin：必需。值可以是具体源（如
http://localhost:3000），或通配符*（但带 cookie 或自定义 header 时不能用*） -
Access-Control-Allow-Methods：列出允许的请求方法，如
GET, POST, PUT, DELETE -
Access-Control-Allow-Headers：如果前端设置了自定义请求头（如
Authorization），这里必须显式列出 -
Access-Control-Allow-Credentials：若前端请求带
credentials: 'include'（比如传 cookie），此项必须为true，且Allow-Origin不能是*
简单请求和预检请求的区别
不是所有跨域请求都一样处理：
-
简单请求（如 GET/POST + 仅限
Content-Type: application/x-www-form-urlencoded等）：浏览器直接发请求，只检查响应头是否合规 -
非简单请求（如 PUT、DELETE、带自定义 header、
Content-Type: application/json）：浏览器会先发一个OPTIONS预检请求，确认服务器是否允许，再发真正的请求。后端必须正确响应这个OPTIONS请求（通常返回 204 状态码 + 正确 CORS 头）
常见误区与应对
前端改代码无法绕过 CORS 限制。以下做法无效或危险：
- 在 fetch 或 axios 中加
mode: 'no-cors'：只能发请求，但拿不到响应体，对业务无用 - 用 JSONP：只支持 GET，已过时，且无错误处理能力
- 禁用浏览器安全策略（如 Chrome 加
--disable-web-security）：仅本地调试可用，上线后用户仍报错，且有严重安全隐患
真正有效的解法只有两个方向：后端配置响应头，或开发阶段用代理（如 Vite 的 server.proxy）让请求“看起来”是同源的。
