浏览器因服务端未返回Access-Control-Allow-Origin响应头而拦截跨域请求；需后端配置CORS头或前端开发期用Vite proxy代理绕过，且credentials为include时Origin不能设为*。
为什么 fetch 会报 “No 'Access-Control-Allow-Origin' header” 错误
这是浏览器主动拦截的，不是你的代码写错了，也不是后端挂了——而是服务端响应里没带 Access-Control-Allow-Origin 这个响应头。浏览器看到请求是跨域（协议、域名、端口任一不同），且响应头缺失该字段，就直接拒绝把响应体交给 JS。你看到的错误只是结果，真正的问题在服务端配置或代理环节。
前端用 fetch 发起跨域请求时必须加 mode: 'cors'
很多人以为只要写了 fetch('https://api.example.com/data') 就行，其实默认 mode 是 'cors'，但一旦你手动加了 credentials: 'include' 却没配 mode，或者用了 mode: 'no-cors'，就会导致：要么被静默降级成 opaque 响应（JS 拿不到任何数据），要么直接报错。正确做法是明确声明：
fetch('https://api.example.com/data', {
method: 'GET',
mode: 'cors', // 必须显式写，尤其配合 credentials 时
credentials: 'include' // 如需带 cookie，后端也得允许 origin 且不能用 *
})-
credentials: 'include'时，后端Access-Control-Allow-Origin不能为*，必须是具体域名 - 开发时若后端未配 CORS，临时用
mode: 'no-cors'是无效的——它只允许发出请求，但 JS 完全读不到响应 - Vite/webpack dev server 的 proxy 是前端开发期绕过 CORS 的常用方式，但它不改变线上行为
本地开发时用 Vite 的 server.proxy 绕过浏览器同源限制
这不是解决 CORS，而是让请求不跨域：把前端请求发给本地开发服务器（如 http://localhost:5173/api/），它再以服务端身份去调真实 API，这样浏览器眼里全是同源请求。Vite 配置示例如下：
export default defineConfig({
server: {
proxy: {
'/api': {
target: 'https://prod-api.example.com',
changeOrigin: true,
rewrite: (path) => path.replace(/^\/api/, '')
}
}
}
})-
changeOrigin: true是关键，它修改请求头中的Host，避免目标服务因 Host 不匹配而拒收 - 这个 proxy 只在
vite dev时生效，build 后的静态文件仍需后端配 CORS 或走 nginx 反向代理 - 不要在 proxy 里尝试加
headers去伪造 CORS 响应头——浏览器根本不看代理层返回的头，它只看最终上游服务的响应
后端必须设置的最小 CORS 响应头组合
光有 Access-Control-Allow-Origin 不够。常见漏配导致 403 或预检失败：
立即学习“前端免费学习笔记（深入）”；
- 简单请求（如 GET + JSON）至少需要：
Access-Control-Allow-Origin+ （可选）Access-Control-Allow-Credentials - 非简单请求（如 POST +
Content-Type: application/json、带自定义 header）会触发 preflight（OPTIONS 请求），此时还需：Access-Control-Allow-Methods、Access-Control-Allow-Headers、Access-Control-Allow-Origin -
Access-Control-Max-Age可减少重复 preflight，建议设为86400（24 小时） - 如果前端用了
credentials: 'include'，后端必须同时设Access-Control-Allow-Credentials: true，且Access-Control-Allow-Origin不能是*
Node.js + Express 示例（注意顺序和条件）：
app.use((req, res, next) => {
res.header('Access-Control-Allow-Origin', 'https://your-frontend.com');
res.header('Access-Control-Allow-Credentials', 'true');
res.header('Access-Control-Allow-Methods', 'GET,PUT,POST,DELETE,OPTIONS');
res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization');
<p>if (req.method === 'OPTIONS') {
res.sendStatus(200);
} else {
next();
}
});CORS 的核心约束不在前端代码里，而在浏览器与服务端的契约中；漏掉任意一个响应头，或前后端 credentials 设置不一致，都会让看似正常的请求突然失败。调试时优先检查 Network 面板里响应头是否齐全，而不是反复改 fetch 参数。
