这是浏览器主动拦截的跨域请求，因服务端未返回access-control-allow-origin等cors响应头；fetch请求已发出且可能返回200，但浏览器在解析响应时直接拒绝，不进入promise链。
为什么 fetch 会报 “No 'Access-Control-Allow-Origin' header” 错误
这是浏览器主动拦截的跨域请求，不是 JavaScript 报错，也不是网络失败，而是服务端没返回正确的 CORS 响应头。核心问题在于：浏览器只允许同源请求读取响应体，除非服务端明确声明允许跨域访问。
常见表现：fetch('https://api.example.com/data') 发出去了（Network 面板能看到 200），但控制台报错、then() 不触发、catch() 捕不到错误——因为根本没进入 Promise 链，是浏览器在解析响应时直接拒绝。
- CORS 是服务端配合的方案，客户端只需正常发请求（如
fetch或XMLHttpRequest） - 预检请求（
OPTIONS）会在发送POST带自定义 header、Content-Type: application/json等情况下自动触发，服务端必须正确响应它 -
前端无法绕过这个限制；禁用浏览器安全策略（如 Chrome 加
--disable-web-security）仅用于本地调试，不可用于生产
JSONP 只能 GET，且不支持现代认证和错误处理
JSONP 是利用 <script></script> 标签不受同源策略限制的“历史技巧”，本质是动态插入 script 标签，服务端返回可执行 JS 代码（如 callback({data: 1})），由全局函数接收数据。
它的局限性非常硬性：
立即学习“Java免费学习笔记（深入）”；
- 只支持
GET请求，无法传 body，不能发POST/PUT/DELETE - 没有标准错误回调：网络失败、超时、404、500 都无法区分，只能靠
setTimeout猜测超时 - 无法携带 cookies、Authorization header 或自定义 header
- 服务端必须支持 JSONP 回调参数（如
?callback=xxx），且要输出合法 JS，有 XSS 风险（若未严格过滤 callback 名） - 现代框架（如 Express、Django REST）默认不提供 JSONP 接口，需手动封装
CORS 的三个关键响应头必须由后端设置
前端改不了这些头，但需要理解它们的作用，以便和服务端同学对齐配置：
-
Access-Control-Allow-Origin：指定允许的源（如https://myapp.com），不能为*同时又带 credentials；若需 cookie，必须写具体域名 -
Access-Control-Allow-Credentials：设为true时，前端fetch必须加{credentials: 'include'}，否则浏览器忽略响应 -
Access-Control-Allow-Headers：列出允许的请求头（如Authorization, Content-Type），预检请求失败常因这个漏配
示例服务端（Express）最小配置：
app.use((req, res, next) => {
res.header('Access-Control-Allow-Origin', 'https://myapp.com');
res.header('Access-Control-Allow-Credentials', 'true');
res.header('Access-Control-Allow-Headers', 'Authorization, Content-Type');
if (req.method === 'OPTIONS') {
res.sendStatus(200);
} else {
next();
}
});
fetch 发送带凭证的跨域请求要显式声明 credentials
很多人以为只要服务端开了 Access-Control-Allow-Credentials: true 就行了，但前端 fetch 默认不带 cookie 和认证信息，必须手动开启：
- 不带凭证（默认行为）：
fetch(url)→ 浏览器不发 cookie，服务端也收不到 session - 带凭证（常用场景）：
fetch(url, { credentials: 'include' })→ 发 cookie、HTTP 认证等 -
'same-origin'表示仅同源时发凭证，跨域时不发；'omit'强制不发（等价于不写） - 如果服务端设了
Access-Control-Allow-Origin: *，又设credentials: true，浏览器会直接拒绝——这是硬性限制，必须指定具体源
一个典型登录后调用接口的写法：
fetch('/api/profile', {
credentials: 'include',
headers: {
'Content-Type': 'application/json'
}
})
.then(r => r.json())
.then(data => console.log(data));
CORS 和 JSONP 不是“选哪个更好”的关系，而是“能不能用”的区别：现在所有主流 API 都只支持 CORS；JSONP 已被标准弃用，仅用于极少数遗留系统或无法修改服务端的极端场景。真正容易被忽略的是 credentials 和预检请求的联动——哪怕 header 写对了，漏掉 OPTIONS 处理或 credentials 不匹配，请求照样静默失败。 
