17370845950

Fetch API 是现代 JavaScript 网络请求首选，语法简洁、原生支持 async/await；错误处理更合理，需显式检查 res.ok；支持流式响应与 AbortController 中断；XHR 仅适用于老 IE 兼容或需精细进度控制等特定场景。

Fetch API 正在成为现代 JavaScript 发起网络请求的首选方式，因为它更简洁、更符合 Promise 语义，且原生支持 async/await；而 XMLHttpRequest（XHR）虽然功能完整、兼容性极好，但接口设计陈旧、回调嵌套繁琐，维护和阅读成本更高。

Fetch 更简洁直观的语法

Fetch 使用函数式调用，一行就能发起 GET 请求，返回 Promise，天然适配 async/await：

• GET 请求只需：const res = await fetch('/api/users');
• JSON 数据可链式解析：const data = await res.json();
• POST 请求配合 body 和 headers 配置清晰明确

错误处理逻辑更合理

Fetch 只有在网络故障（如断网、DNS 失败）时才 reject Promise；HTTP 错误状态（如 404、500）仍返回 resolve 的 Response 对象。这迫使开发者显式检查 res.ok 或 res.status，避免“假成功”陷阱：

• 需手动判断：if (!res.ok) throw new Error(`${res.status} ${res.statusText}`);
• 而 XHR 的 onerror 无法区分 404 和网络中断，容易掩盖问题

原生支持流式响应与中断控制

Fetch 原生提供 Response.body（ReadableStream），适合处理大文件、实时日志或分块渲染；同时结合 AbortController 可优雅取消请求：

立即学习“Java免费学习笔记（深入）”；

• 取消请求只需：const controller = new AbortController(); fetch(url, { signal: controller.signal }); controller.abort();
• XHR 虽可通过 xhr.abort() 中断，但缺乏统一信号机制，难以与 Promise 链协同

XMLHttpRequest 并未淘汰，但适用场景更窄

XHR 仍在需要精细控制上传进度、兼容老版本 IE（≤IE11）、或必须监听底层事件（如 readystatechange、progress）的场景中使用。但新项目中，除非有明确兼容需求，否则应优先选择 Fetch。