从 XMLHttpRequest 到 Fetch API:现代前端网络请求的演进与迁移指南

从 XMLHttpRequest 到 Fetch API:现代前端网络请求的演进与迁移指南
🧑 博主简介ZEEKLOG博客专家历代文学网(PC端可以访问:https://literature.sinhy.com/#/?__c=1000,移动端可关注公众号 “ 心海云图 ” 微信小程序搜索“历代文学”)总架构师,16年工作经验,精通Java编程高并发设计分布式系统架构设计Springboot和微服务,熟悉LinuxESXI虚拟化以及云原生Docker和K8s,热衷于探索科技的边界,并将理论知识转化为实际应用。保持对新技术的好奇心,乐于分享所学,希望通过我的实践经历和见解,启发他人的创新思维。在这里,我希望能与志同道合的朋友交流探讨,共同进步,一起在技术的世界里不断学习成长。
🤝商务合作:请搜索或扫码关注微信公众号 “ 心海云图


在这里插入图片描述

从 XMLHttpRequest 到 Fetch API:现代前端网络请求的演进与迁移指南

引言:为什么我们需要新的网络请求方案?

在前端开发领域,XMLHttpRequest (XHR) 长期统治着浏览器端的网络请求。然而,随着 Web 应用变得越来越复杂,XHR 的设计缺陷和局限性逐渐暴露。2015年,Fetch API 作为更现代、更强大的替代方案出现在 Web 标准中,开启了前端网络请求的新时代。

本文将深入探讨从 XHR 迁移到 Fetch API 的技术细节、优势对比以及实际迁移策略,帮助你理解这一重要技术演进的背后逻辑。

一、XMLHttpRequest 的历史包袱与设计缺陷

1.1 XHR 的基本使用模式

// 典型的 XHR 请求代码var xhr =newXMLHttpRequest(); xhr.open('GET','/api/data',true); xhr.onreadystatechange=function(){if(xhr.readyState ===4){if(xhr.status ===200){var data =JSON.parse(xhr.responseText); console.log('成功:', data);}else{ console.error('请求失败:', xhr.status);}}}; xhr.onerror=function(){ console.error('网络错误');}; xhr.send();

1.2 XHR 的核心问题

回调地狱与复杂的状态管理
XHR 基于事件的回调模式导致代码嵌套层次深,错误处理分散,可读性差。

模糊的错误信息
XHR 的 readyState === 0 状态是最典型的例子 - 它只告诉开发者"请求未初始化",却不提供具体原因。这种模糊性使得调试变得异常困难。

API 设计不直观
需要管理多个事件监听器 (onreadystatechange, onerror, ontimeout),配置复杂,学习曲线陡峭。

功能限制
缺乏对现代 Web 特性(如流式处理、请求中断)的良好支持。

二、Fetch API 的设计理念与核心优势

2.1 Fetch API 的基本使用

// 基础的 Fetch 请求fetch('/api/data').then(response=>{if(!response.ok){thrownewError(`HTTP ${response.status}: ${response.statusText}`);}return response.json();}).then(data=> console.log('成功:', data)).catch(error=> console.error('失败:', error));

2.2 Fetch 的核心设计优势

基于 Promise 的现代化 API

  • 链式调用,避免回调地狱
  • 统一的错误处理机制
  • 更好的异步代码可读性

更精确的错误分类

fetch('/api/data').catch(error=>{// 明确的错误类型if(error.name ==='TypeError'){ console.error('网络错误或 CORS 问题');}elseif(error.name ==='AbortError'){ console.error('请求被取消');}});

对现代 Web 特性的原生支持

  • Service Worker 集成
  • 流式数据处理
  • 请求/响应流的直接访问

三、深度技术对比:XHR vs Fetch

3.1 响应处理机制对比

XHR 的响应处理

xhr.onreadystatechange=function(){if(xhr.readyState ===4){// 所有完成状态都进入这里if(xhr.status ===200){// 成功处理}else{// 所有错误状态统一处理}}};

Fetch 的响应处理

fetch(url).then(response=>{// 关键区别:所有网络成功的请求都进入这里// 包括 200、404、500 等状态码if(response.ok){// 只有 200-299 状态码进入这里return response.json();}elseif(response.status ===304){// 特殊处理缓存情况returnhandleNotModified();}else{// 其他 HTTP 错误状态thrownewHttpError(response.status, response.statusText);}}).catch(error=>{// 只有网络层面的错误进入这里// 如 CORS 错误、DNS 解析失败、网络断开等});

3.2 状态码处理的重大差异

response.ok 的真相

// Fetch 的 response.ok 行为 console.log(response.status);// 200 -> response.ok: true console.log(response.status);// 201 -> response.ok: true  console.log(response.status);// 204 -> response.ok: true console.log(response.status);// 304 -> response.ok: false // 注意! console.log(response.status);// 404 -> response.ok: false console.log(response.status);// 500 -> response.ok: false

这种设计让开发者能够更精确地处理不同的 HTTP 场景,特别是对 304 Not Modified 的特殊处理。

3.3 请求控制能力对比

XHR 的请求控制

var xhr =newXMLHttpRequest(); xhr.open('GET','/api/data',true); xhr.timeout =5000; xhr.ontimeout=function(){ console.log('请求超时');};// 但 XHR 无法真正中止一个超时请求

Fetch 的请求控制

const controller =newAbortController();const signal = controller.signal;// 设置超时setTimeout(()=> controller.abort(),5000);fetch('/api/data',{ signal }).then(response=> response.json()).catch(err=>{if(err.name ==='AbortError'){ console.log('请求被主动取消');}});

四、实际问题解决:状态 0 的谜团

4.1 XHR 状态 0 的根本原因

XHR 的 readyState === 0 表示请求甚至没有成功发送出去,常见原因包括:

  • CORS 跨域问题:浏览器安全策略阻止
  • 网络层阻止:防火墙、代理拦截
  • 代码逻辑错误:在 open()send() 之间发生异常
  • URL 格式错误:协议错误、主机名解析失败

4.2 Fetch 的改进方案

asyncfunctionrobustFetch(url, options ={}){try{const controller =newAbortController();const timeoutId =setTimeout(()=> controller.abort(), options.timeout ||30000);const response =awaitfetch(url,{...options, signal: controller.signal });clearTimeout(timeoutId);if(!response.ok){thrownewHttpError(response.status, response.statusText);}returnawait response.json();}catch(error){// Fetch 提供更明确的错误信息if(error.name ==='AbortError'){thrownewError('请求超时');}elseif(error.name ==='TypeError'){thrownewError('网络错误或 CORS 配置问题');}else{throw error;}}}

五、完整迁移指南与最佳实践

5.1 渐进式迁移策略

创建兼容层

classApiClient{constructor(baseURL =''){this.baseURL = baseURL;this.useFetch =typeof fetch !=='undefined';}asyncrequest(endpoint, options ={}){const url =this.baseURL + endpoint;if(this.useFetch){returnthis.fetchRequest(url, options);}else{returnthis.xhrRequest(url, options);}}asyncfetchRequest(url, options){const controller =newAbortController();const timeoutId =setTimeout(()=> controller.abort(), options.timeout ||30000);try{const response =awaitfetch(url,{ method: options.method ||'GET', headers: options.headers, body: options.body, signal: controller.signal, credentials:'include'});clearTimeout(timeoutId);// 完整的 HTTP 状态码处理switch(response.status){case200:case201:returnawaitthis.parseResponse(response);case204:returnnull;case304:returnthis.handleNotModified(url);case401:thrownewAuthenticationError('请重新登录');case403:thrownewAuthorizationError('没有访问权限');case404:thrownewNotFoundError('资源不存在');case429:thrownewRateLimitError('请求过于频繁');default:if(response.ok){returnawaitthis.parseResponse(response);}thrownewHttpError(response.status, response.statusText);}}catch(error){clearTimeout(timeoutId);throwthis.enhanceError(error, url);}}enhanceError(error, url){if(error.name ==='AbortError'){return{ type:'TIMEOUT', message:`请求超时: ${url}`};}if(error.name ==='TypeError'&& error.message.includes('Failed to fetch')){return{ type:'NETWORK_ERROR', message:`网络连接失败: ${url}`};}return error;}}

5.2 高级特性利用

流式数据处理

// 处理大文件或实时数据流asyncfunctionprocessLargeData(url){const response =awaitfetch(url);const reader = response.body.getReader();while(true){const{ done, value }=await reader.read();if(done)break;// 处理数据块 console.log('接收到数据块:', value.length);}}

请求重试机制

asyncfunctionfetchWithRetry(url, options ={}, maxRetries =3){let lastError;for(let attempt =1; attempt <= maxRetries; attempt++){try{const result =awaitfetch(url, options);return result;}catch(error){ lastError = error;// 只在网络错误时重试if(error.type ==='NETWORK_ERROR'|| error.type ==='TIMEOUT'){const delay = Math.min(1000* Math.pow(2, attempt -1),10000);awaitnewPromise(resolve=>setTimeout(resolve, delay));continue;}// HTTP 错误不重试break;}}throw lastError;}

六、实际业务场景中的迁移考量

6.1 浏览器兼容性处理

// 特性检测与降级方案if(typeof fetch ==='function'&&typeof AbortController ==='function'){// 使用现代 Fetch API module.exports =require('./modern-fetch-client');}else{// 降级到 XHR 或 polyfill module.exports =require('./legacy-xhr-client');}

6.2 与现有代码库的集成

拦截器模式

classFetchInterceptor{constructor(){this.requestInterceptors =[];this.responseInterceptors =[];}use(requestHandler, responseHandler){if(requestHandler)this.requestInterceptors.push(requestHandler);if(responseHandler)this.responseInterceptors.push(responseHandler);}asyncfetch(url, options ={}){// 处理请求拦截器let processedOptions = options;for(const interceptor ofthis.requestInterceptors){ processedOptions =awaitinterceptor(url, processedOptions);}let response =awaitfetch(url, processedOptions);// 处理响应拦截器for(const interceptor ofthis.responseInterceptors){ response =awaitinterceptor(response);}return response;}}

七、性能优化与监控

7.1 请求性能监控

classmonitoredFetch{staticasyncfetch(url, options ={}){const startTime = performance.now();const requestId =generateUniqueId();try{emitEvent('requestStart',{ requestId, url, startTime });const response =awaitfetch(url, options);const endTime = performance.now();emitEvent('requestEnd',{ requestId, url, duration: endTime - startTime, status: response.status, size: response.headers.get('content-length')});return response;}catch(error){const endTime = performance.now();emitEvent('requestError',{ requestId, url, duration: endTime - startTime, error: error.message });throw error;}}}

八、总结:为什么现在应该迁移到 Fetch API

8.1 技术优势总结

  1. 更现代的 API 设计:基于 Promise,支持 async/await
  2. 更精确的错误处理:明确的错误类型和分类
  3. 更好的性能特性:流式处理、请求取消等
  4. 更标准化的规范:WHATWG 标准,持续演进
  5. 更完善的生态系统:与现代框架和工具链深度集成

8.2 业务价值体现

  1. 开发效率提升:代码更简洁,调试更简单
  2. 用户体验改善:更好的错误处理和重试机制
  3. 维护成本降低:统一的技术栈和更少的兼容代码
  4. 技术债务减少:跟上 Web 标准发展,避免被遗留技术束缚

8.3 迁移建议

立即开始:

  • 新项目直接使用 Fetch API
  • 现有项目逐步替换关键的 XHR 调用
  • 建立统一的 HTTP 客户端抽象层

长期规划:

  • 完全移除 XHR 依赖
  • 利用 Fetch 高级特性优化应用性能
  • 参与 Web 标准演进,跟进新的特性

结语

从 XMLHttpRequest 到 Fetch API 的迁移,不仅仅是技术方案的替换,更是前端开发理念的升级。Fetch API 代表了 Web 平台向更现代、更强大方向发展的趋势。

Read more

【OpenClaw从入门到精通】第04篇:Web/TUI/钉钉全打通!OpenClaw多端交互实测指南(2026避坑版)

【OpenClaw从入门到精通】第04篇:Web/TUI/钉钉全打通!OpenClaw多端交互实测指南(2026避坑版)

摘要:本文聚焦OpenClaw三大核心交互方式,针对新手“不知如何与AI助理沟通”的痛点,提供Web控制台、TUI终端、聊天软件(以钉钉为核心)的完整实操流程。Web控制台适配电脑端深度配置,TUI终端适合服务器远程维护,聊天软件满足手机端移动办公,三者协同实现“随时随地召唤AI”。文中包含2026实测的命令代码、配置步骤、问题排查方案,所有案例为虚拟构建,代码未上传GitHub,兼顾新手入门与进阶实操,帮助读者快速打通多端交互,最大化OpenClaw使用效率。 优质专栏欢迎订阅! 【DeepSeek深度应用】【Python高阶开发:AI自动化与数据工程实战】【YOLOv11工业级实战】 【机器视觉:C# + HALCON】【大模型微调实战:平民级微调技术全解】 【人工智能之深度学习】【AI 赋能:Python 人工智能应用实战】【数字孪生与仿真技术实战指南】 【AI工程化落地与YOLOv8/v9实战】【C#工业上位机高级应用:高并发通信+性能优化】 【Java生产级避坑指南:高并发+性能调优终极实战】【Coze搞钱实战:零代码打造吸金AI助手】

By Ne0inhk
Flutter 三方库 tflite_web 端云协同 AI 引擎鸿蒙化高配适配:搭建异构计算 WebGL 后台管线并强力驱动 TensorFlow Lite-适配鸿蒙 HarmonyOS ohos

Flutter 三方库 tflite_web 端云协同 AI 引擎鸿蒙化高配适配:搭建异构计算 WebGL 后台管线并强力驱动 TensorFlow Lite-适配鸿蒙 HarmonyOS ohos

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 tflite_web 端云协同 AI 引擎鸿蒙化高配适配:搭建异构计算 WebGL 后台管线并强力驱动 TensorFlow Lite 轻量大模型推理内核运转 前言 在 OpenHarmony 构建混合架构(Hybrid App)的过程中,将 AI 能力直接下沉到客户端侧执行已成为主流趋势。虽然鸿蒙原生提供了强大的 AI 框架,但对于已有大量积累、且运行在 Flutter Web 容器中的应用而言,寻找一致性的端侧 AI 推理方案至关重要。tflite_web 库为基于 Flutter Web 的应用提供了调用 TensorFlow Lite 模型的能力。本文将调研其在鸿蒙 Web

By Ne0inhk
Flutter for OpenHarmony: Flutter 三方库 cached_query 为鸿蒙应用打造高性能声明式数据缓存系统(前端缓存终极方案)

Flutter for OpenHarmony: Flutter 三方库 cached_query 为鸿蒙应用打造高性能声明式数据缓存系统(前端缓存终极方案)

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net 前言 在进行 OpenHarmony 应用开发时,网络请求的响应速度直接决定了用户体验(体验 UX)。如果用户每次切换页面都必须等待加载动画,应用会显得非常低级。我们不仅需要处理异步数据请求,更需要一套精密的机制来解决以下痛点: 1. 自动缓存:第二次访问时应瞬间展示历史数据。 2. 过期失效(Stale-while-revalidate):在展示旧数据的同时,后台静默拉取新数据。 3. 无限滚动:简单地处理分页与数据追加内容逻辑。 cached_query 是一个类似于 Web 端 React Query 的 Dart 状态管理库。它专注于数据获取与同步,让你的鸿蒙应用具备顶级的数据缓存表现。 一、核心缓存驱动机制 cached_query 在内存与数据源之间建立了一层“智能感知”缓存。 数据过期/缺失 返回新数据 发射流

By Ne0inhk
【踩坑记录】使用 Layui 框架时解决 Unity WebGL 渲染在 Tab 切换时黑屏问题

【踩坑记录】使用 Layui 框架时解决 Unity WebGL 渲染在 Tab 切换时黑屏问题

【踩坑记录】使用 Layui 框架时解决 Unity WebGL 渲染在 Tab 切换时黑屏问题 在开发 Web 应用时,尤其是集成了 Unity WebGL 内容的页面,遇到一个问题:当 Unity WebGL 渲染内容嵌入到一个 Tab 中时,切换 Tab 后画面会变黑,直到用户点击黑屏区域,才会恢复显示。 这个问题通常是因为 Unity 渲染在 Tab 切换时被暂停或未能获得焦点所致。 在本文中,我们将介绍如何在使用 Layui 框架时,通过监听 Tab 切换事件并强制 Unity WebGL 渲染恢复,来解决这一问题。 1. 问题描述 当 Unity WebGL 内容嵌入到页面中的多个

By Ne0inhk