CORS错误由浏览器强制执行，前端无法绕过，只能正确配置请求并捕获错误；服务端必须返回匹配的Access-Control-Allow-Origin等响应头，否则预检失败或响应被拦截。
JavaScript 中的跨域请求不是靠前端“处理”出来的，而是由服务端配合、浏览器策略共同决定的；前端能做的只是正确发起请求并响应预检失败、CORS 报错等信号。
为什么 fetch 或 XMLHttpRequest 会报 CORS 错误
浏览器在发现请求目标域名、协议或端口与当前页面不一致时，会先发一个 OPTIONS 预检请求（非简单请求），若响应头中缺失 Access-Control-Allow-Origin 或值不匹配当前源，就直接拦截响应体，控制台抛出 No 'Access-Control-Allow-Origin' header is present 错误。
- 简单请求（如
GET/POST+Content-Type: text/plain、application/x-www-form-urlencoded、multipart/form-data）可能跳过预检，但仍受响应头限制 -
withCredentials: true时，Access-Control-Allow-Origin不能为*，必须是具体源 - 自定义请求头（如
Authorization、X-Request-ID）必然触发预检
fetch 发起跨域请求的正确写法
前端唯一可控的是请求配置和错误捕获逻辑，而不是绕过 CORS。重点在于：明确是否需要凭证、是否接受 JSON 响应、如何识别真实失败原因。
- 默认不带 cookie：
fetch(url)即可，服务端需返回Access-Control-Allow-Origin: https://your-site.com - 带 cookie 或认证头：必须加
credentials: 'include'，且服务端响应头中Access-Control-Allow-Credentials必须为true - 不要依赖
catch捕获 CORS 错误——它根本不会进catch，而是直接 reject 并在控制台报错；可用try/catch包裹但无法区分网络失败和 CORS 失败 - 检查响应状态前，先确认
response.ok和response.status；若被 CORS 阻止，response.body为空，response.status为 0
fetch('https://api.example.com/data', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
credentials: 'include',
body: JSON.stringify({ id: 123 })
})
.then(r => {
if (!r.ok) throw new Error(`HTTP ${r.status}`);
return r.json();
})
.catch(err => {
// 注意：CORS 拒绝不会进这里，只会 console.error
console.error('Fetch failed:', err);
});
开发阶段绕过 CORS 的真实可行方式
本地调试时，浏览器策略不可禁用，所谓“禁用安全策略启动 Chrome”已失效且不适用于现代版本；唯一稳定可靠的方式是配代理或改服务端响应头。
立即学习“Java免费学习笔记（深入）”；
- Webpack/Vite 等工具的
devServer.proxy或server.proxy是最常用方案，把/api/代理到后端地址，让请求变成同源 - 使用
curl或 Postman 测试接口时不受 CORS 限制，可用于验证服务端是否真返回了正确响应头 - 浏览器插件（如 “CORS Unblock”）仅修改请求头，对预检失败或服务端未返回必要头无效，且上线后毫无作用
- Node.js 中用
http-proxy-middleware自建代理，比前端代理更灵活，适合联调复杂路径
真正卡住人的往往不是怎么写 fetch，而是没意识到：CORS 是浏览器强制执行的安全策略，不是 bug，也不是前端能单方面“解决”的问题；一旦线上出问题，第一反应不该是查 JS 写法，而是立刻用 curl 看服务端响应头有没有 Access-Control-Allow-Origin，以及它的值是否匹配当前页面源。
