17370845950

Fetch API 是 XMLHttpRequest 的更简洁、基于 Promise 的替代方案；其核心差异在于错误处理逻辑不同，fetch 仅网络失败时 reject，HTTP 错误码需手动检查 response.ok。

Fetch API 是浏览器原生提供的、用于发起网络请求的现代 JavaScript 接口，它不是“比 AJAX 好”，而是 XMLHttpRequest（传统 AJAX 的底层实现）的**更简洁、更符合 Promise 设计范式的替代方案**。它不解决所有问题，但在大多数场景下更易用、更可预测。

Fetch 和 XMLHttpRequest 最直观的区别在哪？

核心差异在于控制流和错误处理逻辑：

• fetch() 默认只在**网络失败**（如断网、DNS 错误）时 reject Promise；HTTP 404、500 等响应状态码仍会 resolve，需手动检查 response.ok 或 response.status
• XMLHttpRequest 没有内置 Promise，需手动包装；事件回调（onload、onerror）分散，容易写出“回调地狱”或漏处理状态
• fetch() 不支持同步请求（这是好事），而 XMLHttpRequest 的 async=false 早已被主流浏览器弃用且严重阻塞主线程

为什么 fetch() 的 404 不报错？怎么正确判断失败？

因为 Fetch 规范把“是否成功收到响应”和“响应内容是否有业务意义”做了分离。收到服务器返回（哪怕只是 404 Not Found 的 HTML 页面），就算“网络请求成功”。这反而更贴近真实网络语义。

正确做法是：先检查 response.ok（等价于 response.status >= 200 && response.status ），再解析内容：

fetch('/api/user/123')
  .then(response => {
    if (!response.ok) {
      throw new Error(`HTTP error! status = ${response.status}`);
    }
    return response.json();
  })
  .then(data => console.log(data))
  .catch(err => console.error('请求失败:', err));

fetch() 有哪些 XMLHttpRequest 做不到但实际很需要的功能？

不是“做不到”，而是原生支持、无需额外封装：

• AbortController：轻松取消请求（XMLHttpRequest 需调用 .abort()，但无统一信号机制）
• cache、redirect、integrity 等声明式选项，直接控制缓存策略、重定向行为、子资源完整性校验
• 天然支持 FormData、Blob、ArrayBuffer，上传文件或处理二进制数据更直接
• 流式读取响应体：response.body.getReader() 支持分块读取大文件或实时日志，XMLHttpRequest 只能等整个响应加载完

哪些情况你还得回头用 XMLHttpRequest？

目前（截至 2025 年）仍有两个硬性缺口：

• 上传进度监控：虽然 fetch() + ReadableStream 理论上可行，但浏览器支持不一且实现复杂；XMLHttpRequest.upload.onprogress 仍是最稳定的选择
• 部分老系统要求 IE11 兼容：Fetch 在 IE 中完全不可用，必须降级到 XMLHttpRequest 或使用 polyfill（但 polyfill 无法补全流式 API 或 AbortController）

其他所谓“Fetch 不支持”的功能（比如设置请求头中的 Cookie），其实只是默认行为不同：credentials: 'include' 就能正常发 Cookie，不等于不支持。