有这样一句话：'在前端项目中，网络请求失败不是异常，而是常态。'真正拉开项目工程质量差距的，不是会不会用 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 实例
request = axios.({
: ... || ,
: ,
});
request...(
{
token = .();
(token) {
config.. = ;
}
config;
},
{
.(error);
}
);
request...(
{
{ code, message, data } = response.;
(code !== ) {
.({ : , code, message });
}
data;
},
{
{ response } = error;
(response) {
(response.) {
:
.();
;
:
.();
;
:
.();
;
:
.();
;
:
.();
;
:
.();
}
} (error.) {
.();
} {
.();
}
.(error);
}
);
request;
