Web 项目中 Axios 与 HTTP 状态码的正确打开方式
Web 项目中 Axios 与 HTTP 状态码的正确打开方式
在日常 Web 开发中，我们几乎每天都在和 axios 打交道。但你真的理解它与 HTTP 状态码之间的关系吗？很多开发者对状态码存在误解，导致错误处理逻辑混乱、用户体验差，甚至埋下线上隐患。
本文将结合实战经验，系统梳理 HTTP 状态码分类、常见误区、Axios 默认行为及增强策略，帮助你构建更健壮的前端请求体系。
一、关于状态码的常见错误认知
❌ 误区1：“404 是服务器的问题”
真相：404 属于 4xx 客户端错误。它表示“你请求的资源不存在”，责任在客户端（比如拼错了 URL、访问了已删除的页面）。服务器只是如实告知结果，这恰恰说明服务正常！
✅ 判断标准：如果修正请求（改路径、加参数）就能成功 → 就是客户端问题。
❌ 误区2：“只要返回了 JSON 错误信息，就是业务错误，不算异常”
真相：Axios 的成功/失败判断只看状态码是否在 2xx 范围内，与响应体内容无关。
// 即便服务器返回 { code: 400, msg: "用户名不能为空" }
// 只要状态码是 400，Axios 就会进入 .catch()
axios.post('/register', { username: '' }).then(res => { /* 不会执行 */ }).catch(err => { /* 会执行！*/ });
⚠️ 很多团队把“业务错误”和“HTTP 错误”混为一谈，导致前端不得不在 .catch() 里写大量业务逻辑，代码难以维护。
❌ 误区3：“304 Not Modified 是错误”
真相：304 表示缓存命中，无需重新下载资源，是一种成功的优化行为。但它属于 3xx 重定向类，Axios 默认将其视为失败（因为不是 2xx）！
这意味着如果你不做特殊处理，所有触发 304 的请求都会进 .catch() —— 这显然不合理。
二、HTTP 状态码权威分类（开发必备）
所有 4xx 状态码都表示「客户端错误」（Client Error），
所有 5xx 状态码才表示「服务端错误」（Server Error）。
这是 HTTP 协议的官方定义（RFC 7231 等标准）。
✅ 正确分类
| 状态码范围 | 类型 | 责任方 | 含义说明 |
|---|---|---|---|
| 4xx | 客户端错误 | 客户端 | 请求有问题：格式错、权限不足、资源不存在、方法不对等。服务器理解请求，但拒绝处理或无法处理（因为客户端没按规矩来）。 |
| 5xx | 服务端错误 | 服务端 | 服务器内部出错：代码崩溃、数据库连不上、网关超时等。即使客户端请求完全正确，服务器也无法正常响应。 |
❌ 常见误解澄清
有些人会误以为：
- “404 是服务器没找到资源，所以是服务端的问题？”
- “403 是服务器禁止我访问，是不是服务器配置错了？”
但实际上：
- 404：客户端请求了一个不存在的路径（比如拼错 URL），服务器如实告知“没有这个东西”——这是对客户端错误请求的合理响应。
- 403：客户端已认证，但试图访问无权访问的资源（比如普通用户访问
/admin），服务器拒绝——这是客户端越权，不是服务器故障。
👉 关键判断标准：
如果修正客户端的请求（改 URL、加 Token、换参数、换方法等）就能成功，那就是 4xx（客户端错误）。
如果客户端请求完全正确，但服务器依然挂了或返回异常，那就是 5xx（服务端错误）。
📌 举例对比
| 状态码 | 场景 | 错误类型 | 谁该负责修复？ |
|---|---|---|---|
400 Bad Request | POST 提交的 JSON 缺少必填字段 | 客户端 | 前端/调用方检查参数 |
401 Unauthorized | 没带 Token 或 Token 过期 | 客户端 | 前端应重新登录或刷新 Token |
403 Forbidden | 普通用户访 |