Axios封装中HTTP状态码的归类处理实践

1. 对 axios 封装时 HTTP 状态码归类处理的完整实践

在现代化前端项目中，axios 作为最主流的 HTTP 客户端库，其二次封装质量直接影响项目的开发效率和可维护性。我曾在多个大型项目中负责前端架构设计，发现很多团队对 axios 的封装都停留在基础层面，特别是对 HTTP 状态码的处理往往不够系统化。本文将分享我在企业级项目中总结的完整状态码处理方案。

1.1 为什么需要状态码归类处理？

想象一下这样的场景：你的项目中有上百个 API 请求，每个请求都需要处理 401 未授权、403 禁止访问、500 服务器错误等常见状态码。如果每个请求都单独写一遍状态码判断逻辑，不仅代码冗余，而且当需要调整处理逻辑时（比如 401 从跳转登录页改为静默刷新 token），就需要修改所有相关文件——这简直是维护噩梦。

通过响应拦截器进行统一的状态码归类处理，可以实现：

• 逻辑复用：相同状态码的处理逻辑只写一次
• 集中管理：所有异常处理策略在一个文件中维护
• 业务解耦：业务组件无需关心 HTTP 层细节
• 一致体验：相同错误在全应用有相同的处理方式

1.2 HTTP 状态码分类体系解析

HTTP 状态码虽然数量众多，但可以按照以下维度进行分类处理：

1.2.1 按状态码类别

1.2.2 按业务场景

在实际项目中，我们更关注状态码对应的具体业务含义：

javascript复制const BUSINESS_ERROR_CODES = {
  UNAUTHORIZED: [401, 403],    // 认证/授权问题
  CLIENT_ERROR: [400, 404],    // 客户端请求问题
  SERVER_ERROR: [500, 502, 503], // 服务端问题
  NETWORK_ERROR: ['ECONNABORTED', 'ETIMEDOUT'] // 网络问题
}

1.3 响应拦截器实现方案

下面是一个完整的响应拦截器实现示例，包含状态码