Fetch 是 XMLHttpRequest 的现代替代方案，但默认不带 Cookie、不因 4xx/5xx 状态码 reject、无原生上传/下载进度支持，取消请求需 AbortController。
Fetch API 是浏览器原生提供的、用于发起网络请求的现代 JavaScript 接口，它不是“更高级的 AJAX”，而是 XMLHttpRequest（XHR）的替代方案——设计目标是更简洁、更符合 Promise 语义，但默认行为和错误处理逻辑与传统 AJAX 有关键差异。
Fetch 默认不带 Cookie，而 XHR 默认发送
这是最常踩的坑：即使设置了 withCredentials: true，Fetch 也必须显式传入 credentials 选项，否则跨域请求不会携带 Cookie，登录态直接丢失。
-
fetch(url)→ 不发 Cookie（包括同域） -
fetch(url, { credentials: 'include' })→ 同域/跨域都发 Cookie -
fetch(url, { credentials: 'same-origin' })→ 仅同域发（默认行为其实是'omit'） - XHR 对应的是
xhr.withCredentials = true，且默认为false，但很多旧代码已习惯设为true，迁移到 Fetch 时容易遗漏
Fetch 不把 4xx/5xx 当作 reject，而 XHR 的 onerror 不触发
fetch() 只在网络失败（如断网、DNS 错误、CORS 被拒）时 reject；HTTP 状态码如 404 或 500 仍会 resolve，并返回一个 Response 对象。这和 jQuery.ajax 或封装良好的 XHR 工具库行为不一致，容易导致错误未被捕获。
fetch('/api/user')
.then(res => {
if (!res.ok) {
// 必须手动检查！res.ok 等价于 res.status >= 200 && res.status < 300
throw new Error(`HTTP error: ${res.status}`);
}
return res.json();
})
.catch(err => {
// 这里捕获网络错误 + 手动抛出的业务错误
console.error(err);
});
Fetch 没有 progress 事件，上传大文件时无法监听进度
XHR 支持 xhr.upload.onprogress，Fetch 原生不提供等效机制。如果需要上传进度，必须用 ReadableStream 手动分块读取并上报，或回退到 XHR。
立即学习“Java免费学习笔记（深入）”；
- 下载进度：Fetch 也无法原生监听，
Response.body是ReadableStream，可逐块读取，但需自行计算已读字节数 - 实际项目中，上传大文件且需进度条时，
XMLHttpRequest仍是更稳妥的选择 - 部分 polyfill（如 whatwg-fetch）完全不支持流式读取，仅适用于简单 GET/POST
AbortController 是 Fetch 的取消机制，XHR 用 abort()
Fetch 通过 AbortController 实现请求取消，比 XHR 的 .abort() 更统一（也可用于 setTimeout、Promise.race 等），但需注意兼容性与使用时机。
const controller = new AbortController();
fetch('/api/data', { signal: controller.signal })
.then(res => res.json())
.catch(err => {
if (err.name === 'AbortError') {
console.log('请求已被取消');
}
});
// 3 秒后取消
setTimeout(() => controller.abort(), 3000);
注意：AbortController 在 IE 中不可用，若需兼容，要么降级用 XHR，要么引入 polyfill；另外，controller.abort() 后 Promise 会以 AbortError reject，不是静默终止。
真正难的不是写 fetch，而是记住它不自动处理 Cookie、不因 HTTP 状态码 reject、没有上传进度、取消依赖额外对象——这些“默认不做事”的设计，让开发者更容易写出看似运行、实则漏逻辑的请求代码。
