fetch API 更适合日常使用因其基于 Promise、支持 async/await、语法简洁；但需手动处理 HTTP 错误、显式配置 credentials，而上传进度和中断请求等高级功能仍需 XMLHttpRequest。
fetch API 为什么比 XMLHttpRequest 更适合日常使用
fetch API 是现代浏览器中推荐的网络请求方案，它用 Promise 封装异步操作，天然支持 async/await，避免了 XMLHttpRequest 的回调嵌套和状态管理负担。虽然 XMLHttpRequest 仍被支持，但它的设计更偏向底层控制（比如手动管理 readyState、监听 onprogress），而大多数业务场景并不需要这种粒度。
fetch 不会自动处理 4xx/5xx 响应，这是最容易踩的坑
fetch 只有在网络失败（如断网、DNS 错误）时才 reject，HTTP 状态码如 404 或 500 仍会 resolve，这点和 XMLHttpRequest 的 status 判断逻辑一致，但新手常误以为“没报错就成功”。必须手动检查 response.ok 或 response.status：
const res = await fetch('/api/user');
if (!res.ok) {
throw new Error(`HTTP error: ${res.status}`);
}
const data = await res.json();
fetch 默认不带 cookie，XMLHttpRequest 默认带（取决于 withCredentials）
这是跨域鉴权相关最常出问题的地方。默认情况下，fetch 不发送 cookies，即使后端设置了 credentials: 'include'，也必须显式声明：
-
fetch(url, { credentials: 'include' })—— 类似XMLHttpRequest.withCredentials = true -
credentials: 'same-origin'（默认）—— 同源才发 cookie -
credentials: 'omit'—— 从不发 cookie
而 XMLHttpRequest 在未设置 withCredentials 时，同源请求默认携带 cookie，行为更“隐形”，容易在迁移时遗漏配置。
立即学习“Java免费学习笔记（深入）”；
上传进度、中断请求等高级能力，XMLHttpRequest 仍不可替代
如果项目需要显示文件上传进度、或允许用户主动取消请求，XMLHttpRequest 目前仍是更直接的选择，因为：
-
XMLHttpRequest.upload.onprogress提供原生上传进度事件 -
XMLHttpRequest.abort()可随时中止请求 -
fetch要实现类似功能，得靠AbortController（仅支持取消，不提供上传进度）+ 读取ReadableStream自行分块上传（复杂度高）
所以不是“fetch 全面取代 XMLHttpRequest”，而是“90% 的 GET/POST 场景该用 fetch，剩下 10% 需要精细控制的，还得回退到 XMLHttpRequest”。
