17370845950

这是浏览器主动拦截的跨域请求，因服务端未返回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 标签，服务端返回可执行 JS 代码（如 callback({data: 1})），由全局函数接收数据。

它的局限性非常硬性：

• 只支持 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 不匹配，请求照样静默失败。