cors是浏览器强制实施的跨域资源共享协议，通过检查响应头（如access-control-allow-origin）决定是否允许跨域请求；预检请求需返回200及对应头；服务端配置关键响应头、前端正确设置credentials选项，并利用开发代理绕过cors限制。
CORS 是浏览器对跨域请求的强制校验机制
不是“有关系”，而是 CORS 就是浏览器实现跨域资源共享（Cross-Origin Resource Sharing）的具体协议。当 JavaScript 发起 fetch 或 XMLHttpRequest 请求目标域名与当前页面协议、域名、端口任一不同时，浏览器就会触发 CORS 检查——它不拦请求本身，而是在收到响应后检查响应头是否允许当前源访问。
常见错误现象：Access to fetch at 'https://api.example.com/data' from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
- 这个报错一定发生在浏览器控制台，且服务端日志里通常能看到请求已到达（说明不是网络拦截，是浏览器主动拒绝）
- 预检请求（
OPTIONS）失败时，错误信息可能更模糊，比如Failed to fetch但没具体提示，需看 Network 面板确认是否发出了OPTIONS -
file://协议下所有跨域请求都会被禁用，且不走 CORS 流程（直接拒绝），这不是配置问题，是浏览器安全策略硬限制
服务端必须返回正确的 CORS 响应头
前端改不了 CORS，能做的只有配合；真正起作用的是服务端在响应中设置的几个关键头：
-
Access-Control-Allow-Origin：必须精确匹配或为*（但*不允许带凭证） -
Access-Control-Allow-Credentials：设为true时，Access-Control-Allow-Origin不能为*，必须指定具体源 -
Access-Control-Allow-Headers：若请求带自定义头（如Authorization、X-Request-ID），必须在此声明 -
Access-Control-Allow-Methods：列出允许的 HTTP 方法，如GET, POST, PUT - 预检请求（
OPTIONS）必须返回 200 状态码，且包含上述头，否则后续请求不会发出
示例（Express 中间件）：
app.use((req, res, next) => {
res.header('Access-Control-Allow-Origin', 'http://localhost:3000');
res.header('Access-Control-Allow-Credentials', 'true');
res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE');
res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization');
if (req.method === 'OPTIONS') {
return res.sendStatus(200);
}
next();
});
前端 fetch 的 credentials 选项决定是否携带 Cookie
fetch 默认不发送 Cookie，即使服务端允许凭据，前端也得显式声明：
- 不带认证信息：默认行为，
credentials: 'omit'（可省略） - 带 Cookie 和 HTTP 认证：必须设
credentials: 'include'，且服务端Access-Control-Allow-Origin不能为* - 只在同源时发凭证：用
credentials: 'same-origin'，跨域时自动忽略凭证（极少用）
错误写法示例：
fetch('https://api.example.com/login', {
method: 'POST',
credentials: 'include', // ✅ 必须加
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ user: 'a' })
});
漏掉 credentials: 'include' 会导致登录接口看似成功（服务端收到请求并返回 session），但后续请求仍 401——因为 Cookie 根本没发过去。
开发阶段绕过 CORS 的真实可行方案
本地开发时，后端还没配好 CORS，别用插件或禁用浏览器安全策略（不稳定、误导判断）。最可靠的是利用开发服务器的代理能力：
- Vite：在
vite.config.ts中配server.proxy，把/api/代理到后端地址，请求发给http://localhost:5173/api/users，实际走代理，仍是同源 - Create React App：在
package.json加"proxy": "http://localhost:8000"，所有未匹配静态资源的请求自动转发 - Webpack Dev Server：用
devServer.proxy，支持重写路径和 cookie 转发
注意：代理只在开发环境生效，构建后的生产代码仍需服务端正确配置 CORS；另外，代理无法解决第三方 API（如微信 JS-SDK 的 https://api.weixin.qq.com）的跨域问题，这类必须走自己后端中转。
真正容易被忽略的是：CORS 规则对重定向（302）无效——如果请求被重定向到另一个源，浏览器会重新发起请求，并对新地址再次执行完整 CORS 校验。这意味着，哪怕你代理配置了重定向，也可能因跳转后跨域而失败。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
