【前端实战】Axios 错误处理的设计与进阶封装,实现网络层面的数据与状态解耦

【前端实战】Axios 错误处理的设计与进阶封装,实现网络层面的数据与状态解耦

目录

【前端实战】Axios 错误处理的设计与进阶封装,实现网络层面的数据与状态解耦

一、为什么网络错误处理一定要下沉到 Axios 层

二、Axios 拦截器 interceptors

1、拦截器的基础应用

2、错误分级和策略映射的设计

3、错误对象标准化

三、结语


        作者:watermelo37

        ZEEKLOG优质创作者、华为云云享专家、阿里云专家博主、腾讯云“创作之星”特邀作者、火山KOL、支付宝合作作者,全平台博客昵称watermelo37。

        一个假装是giser的coder,做不只专注于业务逻辑的前端工程师,Java、Docker、Python、LLM均有涉猎。



---------------------------------------------------------------------

温柔地对待温柔的人,包容的三观就是最大的温柔。

---------------------------------------------------------------------

【前端实战】Axios 错误处理的设计与进阶封装,实现网络层面的数据与状态解耦

        有这样一句话:“在前端项目中,网络请求失败不是异常,而是常态。”真正拉开项目工程质量差距的,不是会不会用 axios,而是如何设计一套可维护、可扩展、可协作的网络错误处理体系。成熟的项目组有现成可用的axios网络封装设计,不成熟的项目组网络错误处理原始而杂乱,很多开发者在成熟的项目组开发了多年,依然不了解Axios 错误处理的设计封装,只处在知道有这个东西,而不知道如何设计的状态下。本文围绕 Axios 的拦截器机制,系统性分析可配置、可分级、可扩展的网络请求实战封装策略。

一、为什么网络错误处理一定要下沉到 Axios 层

        在项目中,如果常规错误处理放在业务层,就会需要给每个 async/await 都要写一段 try-catch,同一种错误(如 token 过期)被处理 N 次,UI 提示风格难以统一,后续想要改动极其痛苦:

// 典型的业务层污染 async function loadList() { try { const res = await getList() list.value = res.data } catch (e) { ElMessage.error('请求失败') } } 

        这肯定是不可取的,应该将错误分级并合并统一处理。对于网络错误的判断逻辑、分类、兜底策略,本就应该属于请求基础设施层。

二、Axios 拦截器 interceptors

        Axios 提供了两个关键拦截器,分别是请求拦截器和响应拦截器,可以用来行使不同的职责。

1、拦截器的基础应用

        网络请求一般有两大类失败,其一是HTTP / 网络层错误,比如断网、请求超时、上游错误(500/502/503)等。其二是业务层错误,比如 code !== 0(响应状态码是200,但业务状态异常)、token过期、权限问题等。

// src/utils/api.js import axios from 'axios'; import { ElMessage } from 'element-plus'; // 创建 axios 实例 const request = axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL || '/api', timeout: 10000, }); // 请求拦截器(可选:添加 token 等) request.interceptors.request.use( (config) => { // 例如:从 localStorage 获取 token 并添加到请求头 const token = localStorage.getItem('token'); if (token) { config.headers.Authorization = `Bearer ${token}`; } return config; }, (error) => { return Promise.reject(error); } ); // 响应拦截是集中处理错误的核心 request.interceptors.response.use( (response) => { const { code, message, data } = response.data if (code !== 0) { return Promise.reject({ type: 'business', code, message }) } return data }, (error) => { const { response } = error; if (response) { // 有响应(HTTP 状态码 4xx / 5xx) switch (response.status) { case 400: ElMessage.error('请求参数错误'); break; case 401: ElMessage.error('未授权,请重新登录'); // 可跳转到登录页 // window.location.href = '/login'; break; case 403: ElMessage.error('拒绝访问'); break; case 404: ElMessage.error('请求资源不存在'); break; case 500: ElMessage.error('服务器内部错误'); break; default: ElMessage.error(`请求失败:${response.status}`); } } else if (error.request) { // 请求已发出但无响应(如网络错误、超时) ElMessage.error('网络异常,请检查网络连接'); } else { // 其他错误(如配置错误) ElMessage.error('请求配置错误'); } return Promise.reject(error); } ); export default request;

        此时业务层已经做到了数据与状态的解耦,状态问题和错误信息全部在拦截器阶段处理,返回给业务调用接口位置的只有数据:

// 在响应拦截器里面,返回的是response.data.data,所以业务层里面只会拿到数据 const data = await api.getUser() 

        这样业务层就不用关心 HTTP状态码和后端返回的具体结构,也不用对请求错误类型进行具体的区分了。

2、错误分级和策略映射的设计

        错误的严重程度是有等级的,不应该把所有的错误都按相同的方式处理,比如401,一般情况下应该去实现用户无感刷新,请求失败再提示用户重新登陆。

        只需要加上一个简单的策略映射设计:

const errorHandlers = { 401() { logout() router.push('/login') }, 403() { ElMessage.error('没有权限') }, default(err) { ElMessage.error(err.message || '请求失败') } } 

        并在拦截器中统一调度:

function handleBusinessError(err) { const handler = errorHandlers[err.code] || errorHandlers.default handler(err) } 

        这样就能根据状态码的不同,映射不同的处理方法,长期维护和拓展问题也解决了。

3、错误对象标准化

        很多项目后期痛苦的根源是 error 有时候是 string,有时候是 AxiosError,有时候是后端对象,所以需要永久地将错误处理的复杂度从业务层转移到基础设置层(即Axios)。以此来实现一个架构层面的收益。

        比如定义一个标准错误结构(这部分代码仅ts需要):

interface AppError { type: 'network' | 'business' code?: number message: string raw?: any } 

        然后在 Axios 层构造,举个例子:

axios.interceptors.response.use( res => { if (res.data.code !== 0) { return Promise.reject({ type: 'business', code: res.data.code, message: res.data.msg, raw: res }) } return res.data.data }, error => { return Promise.reject({ type: 'network', message: '网络异常,请稍后重试', raw: error }) } ) 

        那么在业务层就只需要面对一种 error 类型了,不用操心错误类型,业务代码降维:

try { await api.save() ElMessage.success('保存成功') } catch (err) { ElMessage.error(err.message) } 

三、结语

        一个成熟的 Axios 错误处理体系,应该能做到错误集中处理,业务代码干净,错误分级,有明确策略,错误结构统一,方便扩展,自然接入登录、权限、数据监控等模块。错误处理不是异常流程,而是系统设计的一部分。做好网络层的错误处理,实现数据与状态的解耦,会让业务层开发大有裨益。

         只有锻炼思维才能可持续地解决问题,只有思维才是真正值得学习和分享的核心要素。如果这篇博客能给您带来一点帮助,麻烦您点个赞支持一下,还可以收藏起来以备不时之需,有疑问和错误欢迎在评论区指出~

        其他热门文章,请关注:

        极致的灵活度满足工程美学:用Vue Flow绘制一个完美流程图

        你真的会使用Vue3的onMounted钩子函数吗?Vue3中onMounted的用法详解

        Web Worker:让前端飞起来的隐形引擎

        测评:这B班上的值不值?在不同城市过上同等生活水平到底需要多少钱?

        通过array.filter()实现数组的数据筛选、数据清洗和链式调用

        DeepSeek:全栈开发者视角下的AI革命者

        TreeSize:免费的磁盘清理与管理神器,解决C盘爆满的燃眉之急

        通过Array.sort() 实现多字段排序、排序稳定性、随机排序洗牌算法、优化排序性能

        高效工作流:用Mermaid绘制你的专属流程图;如何在Vue3中导入mermaid绘制流程图

        通过MongoDB Atlas 实现语义搜索与 RAG——迈向AI的搜索机制

      【前端实战】如何让用户回到上次阅读的位置?

        前端实战:基于Vue3与免费满血版DeepSeek实现无限滚动+懒加载+瀑布流模块及优化策略

        深入理解 JavaScript 中的 Array.find() 方法:原理、性能优势与实用案例详解

        el-table实现动态数据的实时排序,一篇文章讲清楚elementui的表格排序功能

        JavaScript双问号操作符(??)详解,解决使用 || 时因类型转换带来的问题

        内存泄漏——海量数据背后隐藏的项目生产环境崩溃风险!如何避免内存泄漏

        MutationObserver详解+案例——深入理解 JavaScript 中的 MutationObserver

        JavaScript中通过array.map()实现数据转换、创建派生数组、异步数据流处理、DOM操作等

Read more

3分钟突破Home Assistant插件下载限制:HACS极速版让智能家居秒速响应

3分钟突破Home Assistant插件下载限制:HACS极速版让智能家居秒速响应 【免费下载链接】integration 项目地址: https://gitcode.com/gh_mirrors/int/integration 还在为Home Assistant插件安装慢而抓狂?深夜调试智能家居时插件下载失败,看着进度条卡在99%动弹不得;早上急着出门想添加新设备,却因为GitHub连接超时只能干瞪眼?现在这些烦恼都将成为过去!HACS极速版专为中国用户打造,通过智能加速技术彻底解决Home Assistant插件下载难题,让你轻松享受流畅的智能家居体验。无论是新手还是资深玩家,都能通过这款工具实现Home Assistant插件加速,告别GitHub资源国内下载的困扰。 🚨 智能家居的"堵车"困境:你是否也经历过这些崩溃瞬间? 想象一下这些场景: 深夜抢修的绝望 周末深夜,家里的智能灯光突然失控,你好不容易找到修复教程,却卡在"安装依赖插件"这一步——GitHub的下载速度只有5KB/s,进度条像蜗牛一样爬行。眼看就要天亮,你却只能对着&

68.72亿元!智能家居芯片市场规模锁定,技术迭代催生行业新增长极

68.72亿元!智能家居芯片市场规模锁定,技术迭代催生行业新增长极

在全球智能家居设备渗透率持续提升的背景下,智能家居芯片作为设备智能化升级的核心组件,正迎来结构性增长机遇。据恒州诚思最新调研数据显示,2025年全球智能家居芯片市场规模预计达68.72亿元,至2032年将增长至150.5亿元,期间年复合增长率(CAGR)为11.9%。这一增长受三大核心因素驱动:其一,全球智能家居设备出货量快速增长(2025年预计达18.2亿台,CAGR为12.5%),带动芯片需求激增;其二,AIoT(人工智能物联网)技术深度融合,推动芯片向高算力、低功耗方向迭代(2025年AIoT芯片占比预计达45%);其三,中国等新兴市场政策支持(2023年中国《智能家居互联互通标准》发布,推动设备兼容性提升),为芯片企业提供增量空间。 一、全球市场波动与头部企业格局演变 全球智能家居芯片市场受宏观经济周期影响显著。2022年,受全球通胀压力(美国CPI同比上涨8.0%)及地缘政治冲突(俄乌冲突导致供应链中断)影响,芯片出货量同比下滑5.2%;2023年,随着供应链逐步修复(全球半导体库存周转天数从120天降至90天),下滑幅度收窄至2.

2026 年最值得关注的开源低代码 / 零代码平台推荐

2026 年最值得关注的开源低代码 / 零代码平台推荐

无论是零代码小白还是资深开发者,都能在这些平台上找到适合自己的解决方案。今天,我们就来盘点一下 2026 年最值得关注的开源低代码 / 零代码平台,帮助您找到最适合的工具。 一、敲敲云 - 永久免费开源零代码平台 2026 年 1 月 12 日,敲敲云全新版本 v2.3.0 正式发布! 这一版本最大的亮点是正式宣布永久免费开放,彻底打破了传统零代码平台的用户数、应用数、表单数等多重限制,实现真正的零门槛、零成本使用。 敲敲云专注于为企业快速构建应用和工作流,是一款强大且易用的零代码平台。用户无需编写任何代码,即可通过丰富的组件库轻松创建各类应用,真正做到了 "人人都是开发者"。 产品特点: * 免费零代码使用,快速上手,无需开发背景 * 丰富的组件库和模板,满足多样化应用需求 * 可视化流程设计器,支持拖放式工作流设计 * 强大的工作流引擎,支持复杂流程逻辑与条件判断 * 优秀的团队协作功能,支持资源共享和协同开发 * 数据收集能力强,

机器人操作VLA模型的强化学习:综述

机器人操作VLA模型的强化学习:综述

25年12月来自新加坡南洋理工、北邮和清华的论文“A Survey on Reinforcement Learning of Vision-Language-Action Models for Robotic Manipulation”。 构建能够执行各种操作任务的通用机器人系统的愿景已通过视觉-语言-动作模型(VLA)得到显著推进。VLA利用大规模预训练,通过模仿学习获取通用的视觉运动先验知识。然而,目前的预训练VLA仍需微调才能适应实际部署,因为传统的模仿学习由于依赖于状态和动作覆盖范围有限的已收集数据集,难以实现分布外(OOD)泛化。强化学习(RL)利用自探索和结果驱动优化来增强VLA的OOD泛化能力。本文概述RL如何弥合预训练和实际部署之间的差距,并全面介绍RL-VLA的训练范式。分类体系围绕四个核心维度展开,反映从学习到部署的完整生命周期:RL-VLA架构、训练范式、实际部署以及基准测试和评估。首先,介绍RL-VLA组件的关键设计原则,包括动作、奖励和转换建模。其次,回顾在线、离线和测试时RL范式,分析它们在提升VLA泛化能力方面的有效性和挑战。第三,考察实际部署框架,从仿