fetch api 并未完全替代 xmlhttprequest，因其在 cookie 发送（需显式 credentials: 'include'）、错误处理（4xx/5xx 不 reject）、上传进度监听（不支持）、超时控制（需 abortcontroller 模拟）等方面存在短板，复杂场景仍需 xmlhttprequest 或封装库。
Fetch API 比 XMLHttpRequest 更简洁、更符合现代 JS 习惯，但不是“完全替代”——它在错误处理、上传进度、取消请求等场景下有明显短板，需搭配 AbortController 或第三方库补足。
fetch 默认不带 cookie，XMLHttpRequest 默认带（取决于 withCredentials）
这是最常踩的坑：用 fetch 发请求时，即使用户已登录，后端收不到 session cookie，导致 401。
-
fetch必须显式传{ credentials: 'include' }才会发送 cookie -
XMLHttpRequest在同域下默认发送 cookie；跨域时需手动设xhr.withCredentials = true - 若后端是 Express +
cors({ credentials: true })，前端漏掉credentials: 'include'就一定失败
fetch('/api/user', {
credentials: 'include' // 必须写！否则 cookie 不发
})
fetch 不把 4xx/5xx 当作 reject，XMLHttpRequest 的 onerror 也不捕获它们
fetch 只在网络断开、DNS 失败、被 CORS 阻止等真正“请求没发出去”时才 reject；HTTP 状态码 400、500 都算“成功”，得靠 response.ok 或 response.status 手动判断。
-
XMLHttpRequest同样不会因 404 自动触发onerror，也得检查xhr.status - 区别在于：fetch 的 Promise 链容易让人误以为“没报错=成功”，结果漏处理业务错误
- 建议统一加一层封装，自动 throw 错误
async function safeFetch(url, options = {}) {
const res = await fetch(url, options);
if (!res.ok) throw new Error(`HTTP ${res.status}: ${res.statusText}`);
return res;
}
fetch 不支持上传进度监听，XMLHttpRequest 支持 upload.onprogress
做大文件上传时，fetch 没法原生获取上传百分比；而 XMLHttpRequest 的 xhr.upload.onprogress 是稳定可用的。
立即学习“Java免费学习笔记（深入）”；
- 目前唯一标准方案是用
XMLHttpRequest处理上传，fetch处理普通请求 - 社区有
fetch-upload-progress这类包装库，但本质仍是用XMLHttpRequest实现 - Chrome 126+ 开始实验
ReadableStream上传，但兼容性极差，不可用于生产
fetch 没有内置超时，XMLHttpRequest 有 timeout 属性
fetch 本身不提供 timeout 参数，必须靠 AbortController + setTimeout 模拟：
-
XMLHttpRequest.timeout = 5000是原生支持，简单直接 -
fetch要写更多代码，且AbortController无法区分是超时还是用户主动取消 - 注意：
AbortController.abort()后，fetch Promise 会以AbortErrorreject，需专门 catch
const controller = new AbortController();
setTimeout(() => controller.abort(), 5000);
try {
const res = await fetch('/api/data', { signal: controller.signal });
} catch (err) {
if (err.name === 'AbortError') console.log('请求超时');
}
真正用起来，fetch 的语法糖优势只在简单 GET/POST 场景明显；一旦涉及上传、超时、cookie、重试、拦截，XMLHttpRequest 或 axios 这类封装库反而更稳——别迷信“新就是好”。
