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 ），再解析内容：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“Java免费学习笔记（深入）”；
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？
目前（截至 2024 年）仍有两个硬性缺口：
- 上传进度监控：虽然
fetch()+ReadableStream理论上可行，但浏览器支持不一且实现复杂；XMLHttpRequest.upload.onprogress仍是最稳定的选择 - 部分老系统要求 IE11 兼容：Fetch 在 IE 中完全不可用，必须降级到
XMLHttpRequest或使用 polyfill（但 polyfill 无法补全流式 API 或AbortController）
其他所谓“Fetch 不支持”的功能（比如设置请求头中的 Cookie），其实只是默认行为不同：credentials: 'include' 就能正常发 Cookie，不等于不支持。
