XMLHttpRequest（XHR）和Fetch是浏览器中两种HTTP请求机制：XHR兼容性广、控制精细但API冗长，Fetch语法简洁、基于Promise但需注意credentials和错误处理。
XMLHttpRequest（XHR）是浏览器提供的一个内置对象，用于在客户端与服务器之间发送 HTTP 请求并处理响应。它最早由微软在 IE5 中以 ActiveX 对象形式引入，后来被 W3C 标准化，成为原生支持 AJAX 的核心机制。Fetch 是 ES6 之后提出的现代替代方案，基于 Promise 设计，语法更简洁、语义更清晰。
功能覆盖范围不同
XHR 支持非常细粒度的控制：可以手动设置请求头、监听上传/下载进度、中止请求、处理流式响应（通过 responseType = 'stream'）、甚至处理二进制数据（如 ArrayBuffer、Blob）。Fetch 默认不提供上传进度监听，也不直接暴露底层连接状态；虽然可通过 ReadableStream 分块读取响应体，但对上传过程无原生支持。
- XHR 可通过
xhr.upload.onprogress监听文件上传进度 - Fetch 没有等效的上传事件，需借助第三方库或服务端配合实现进度反馈
- XHR 支持同步请求（
async = false），但已被弃用且会阻塞主线程；Fetch 始终异步，不支持同步模式
错误处理逻辑不一样
XHR 将网络失败（如断网）、超时、跨域拒绝等都归为 onerror 事件，而 HTTP 状态码（如 404、500）仍会进入 onload，需要手动判断 status。Fetch 则只在“网络异常”时 reject Promise，而 4xx/5xx 状态码仍被视为成功响应，必须显式检查 response.ok 或 response.status。
- XHR 示例：
if (xhr.status >= 400) { /* 处理业务错误 */ } - Fetch 示例：
if (!response.ok) throw new Error(`HTTP error: ${response.status}`) - Fetch 更容易漏掉对
response.ok的检查，导致“请求发出去了却没报错”的假成功现象
使用方式和兼容性差异明显
XHR 是命令式 API，需创建实例、配置、注册回调、调用 send()；步骤多、易出错。Fetch 是函数式风格，一行即可发起 GET 请求，配合 async/await 写法更直观。不过 Fetch 在旧版 Safari 和 IE 中完全不可用，而 XHR 自 IE5 起就存在，兼容性极广。
立即学习“Java免费学习笔记（深入）”；
- 简单 GET 请求：XHR 需 5–7 行代码，Fetch 通常 1–2 行
- 需要兼容 IE11 或老版本移动端时，仍需用 XHR 或封装好的 polyfill
- 现代项目若无需兼容老旧环境，Fetch + AbortController（控制中断）已能覆盖绝大多数场景
Cookie 和认证行为默认不同
XHR 默认携带 Cookie（取决于同源策略和 CORS 设置），而 Fetch 默认不发送 Cookie，必须显式传入 { credentials: 'include' } 才会带上。这对登录态保持、CSRF 防护等场景影响较大。
- 忘记加
credentials: 'include'是 Fetch 常见的 401 错误原因 - XHR 的默认行为更贴近传统表单提交，Fetch 则更“纯净”，把选择权交给开发者
- 两者都受 SameSite Cookie 属性和 CORS 配置约束，不能绕过安全限制
