17370845950

Fetch API 是 Promise-based 且支持 async/await，但成功 resolve 不代表 HTTP 成功（需检查 response.ok），默认不带 Cookie、无超时和上传进度监听，错误处理仅覆盖网络层而非 HTTP 状态码。

Fetch API 是 Promise-based，而传统 Ajax（XMLHttpRequest）是事件驱动

这意味着 fetch() 天然支持 async/await 和链式 .then()，不用手动监听 onreadystatechange 或判断 readyState === 4。但也要注意：fetch() 成功返回的 Promise 并不等价于 HTTP 成功（比如 404、500 仍会 resolve），必须显式检查 response.ok 或 response.status。

• XMLHttpRequest 需要手动设置 open()、send()、监听 load 或 error 事件
• fetch() 默认只 reject 网络失败（如断网、DNS 错误），HTTP 状态码异常不会触发 catch
• 没有内置超时机制 —— XMLHttpRequest 可设 timeout 属性，fetch() 得靠 AbortController 模拟

默认不带 Cookie，传统 Ajax 默认携带

这是最常踩的坑：fetch() 默认 credentials 为 'omit'，跨域请求完全不发 Cookie；而 XMLHttpRequest 在同域或设置了 withCredentials = true 后会自动带上。

• 需要鉴权时，必须显式传 { credentials: 'include' }（或 'same-origin'）
• 若后端用 Access-Control-Allow-Origin: *，则不能设 credentials: 'include'，否则浏览器直接拒绝请求
• 服务端需配 Access-Control-Allow-Credentials: true 且 Access-Control-Allow-Origin 不能为通配符

不支持上传进度监听，XMLHttpRequest 支持 upload.onprogress

如果要做文件上传进度条，fetch() 无法原生满足 —— 它没有类似 XMLHttpRequest.upload.onprogress 的钩子。目前只能靠 ReadableStream + TransformStream 手动分块读取并计算进度（兼容性差），或退回到 XMLHttpRequest。

• fetch() 的 body 是一次性写入的，无法中途拦截或观测发送过程
• XMLHttpRequest 的 upload 对象暴露了 onprogress、onloadstart、onloadend 等完整生命周期
• 某些 polyfill（如 whatwg-fetch）也不补全上传进度能力

错误处理逻辑完全不同：网络失败 vs HTTP 错误

很多人以为 catch 能捕获 404，结果发现根本进不去 —— 因为 fetch() 对 404、500 这类响应仍视为“成功”，只是返回一个 Response 对象。真正的错误只有网络层中断、CORS 拒绝、URL 解析失败等。

fetch('/api/user')
  .then(response => {
    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }
    return response.json();
  })
  .catch(err => {
    // 这里只捕获网络错误、AbortError、CORS 错误等
    // 404/500 不会进到这里，除非上面手动 throw
  });

• response.status 是数字，response.statusText 是字符串（如 'Not Found'）
• response.type 可区分 'basic'、'cors'、'opaque'，影响能否读取 headers 或 body
• 流式读取（response.body.getReader()）不可重复消费，调过 json() 就不能再调 text()

实际项目中，是否用 fetch() 不只看“新旧”，得看有没有上传进度、是否依赖 Cookie、后端 CORS 配置是否配合 —— 很多看似简单的迁移，卡在 credentials 和 response.ok 上。