HTTP状态码，这5个最常用

很多人看到后端返回400、500，第一反应是「后端有问题」。但实际上，很多问题出在请求本身。经验丰富的开发者，往往看一眼状态码就知道该查谁的问题。

今天分享我日常最常打交道的5个状态码，以及对应的排查思路。

1. 400 Bad Request：请求本身有问题

这个锅通常在前端。

常见原因就那么几个：参数漏了、格式不对、编码有问题。我遇到最多的是这两种：

一是必填参数没传。 比如某个接口要求传userId，你漏掉了，后端一解析直接报错。

二是JSON格式不对。 特别容易出现在手写请求体的时候，少个逗号、多个括号，400就来了。

排查技巧：

• 打开浏览器Network面板，看请求体里到底发的是什么
• 用curl或Postman复现请求，看返回的具体错误信息
• 后端通常会在响应body里告诉你哪个字段有问题

// 常见错误：Content-Type不匹配
fetch('/api/user', {
  method: 'POST',
  body: JSON.stringify(data), // 数据是JSON
  headers: {
    'Content-Type': 'application/x-www-form-urlencoded' // 头部写错了！
  })
})

2. 401 Unauthorized：身份没通过

这个状态的本质是「你不认识」或「你的凭证过期了」。

两种常见场景：

一是没登录就访问需要授权的接口。 这种情况前端要判断是否跳转登录页。

二是Token过期了。 特别是Bearer Token，很多后端会设个几小时的有效期。

排查技巧：

• 先确认本地存储的Token还在不在
• 看请求头里有没有带Authorization
• 检查Token格式是否正确（通常是Bearer xxx）
• 如果用的是JWT，试试用在线工具解码payload部分，看exp字段有没有过期

// 正确写法
const token = localStorage.getItem('access_token');
fetch('/api/protected', {
  headers: {
    'Authorization': `Bearer ${token}`
  }
})

3. 403 Forbidden：你没权限

这个和401容易混淆。简单说：401是"不认识你"，403是"认识你但不让你进"。

常见场景：

• 普通用户访问管理员接口
• 登录了，但某些功能需要额外权限
• IP被后端拉黑了

排查技巧：

• 确认当前账号的权限级别
• 看接口文档里这个接口需要什么权限
• 如果是测试环境，问后端是不是在白名单里

4. 404 Not Found：资源不存在

这个状态码很诚实——找不到就是找不到。

但容易忽略的一个细节是：同样是404，可能是前端路由问题，也可能是后端接口真没了。

排查思路：

• 先确认请求URL拼对了没有
• 检查后端是不是悄悄改了接口路径
• 如果是SPA应用，看是不是前端Router没匹配上

// 容易犯的错：多余的斜杠
// 错误
fetch('/api/users//profile')  // 双斜杠
// 正确
fetch('/api/users/profile')

5. 500 Internal Server Error：后端炸了

这是最让人头疼的，因为问题可能出在任何地方。

但从联调角度，我有兩個快速定位思路：

一是看响应body。 后端如果返回了堆栈信息，能直接定位到具体文件和行号。

二是查后端日志。 很多500错误后端已经记录了，你直接问后端要日志比自己猜快一百倍。

有个坑要提醒：有时候前端超时也会触发500，因为后端等太久直接抛异常了。如果你的请求特别慢，优先看看是不是接口本身响应时间长。

// 建议：添加超时处理
const controller = new AbortController();
const timeout = setTimeout(() => controller.abort(), 5000);

fetch('/api/slow-endpoint', { signal: controller.signal })
  .catch(err => {
    if (err.name === 'AbortError') {
      console.log('请求超时，可能是接口本身太慢');
    }
  })
  .finally(() => clearTimeout(timeout));

状态码速查表

写在最后

状态码是前后端沟通的第一道语言。看懂这5个，最少能覆盖日常80%的联调问题。

我的习惯是：拿到接口文档先扫一遍所有可能的状态码和对应含义，而不是踩坑了再去查。这样联调效率至少能提升一半。

下次再看到500，别急着喊后端。先看看是不是自己请求有问题。排除了前端，再去找后端也不迟。