周五晚上，你看到了一个500

周五晚上，你在加班验证一个刚上线的功能。

你打开页面，输入信息，点击提交。

页面上弹出一个提示：“500 Error。”

你愣住了。500是什么？是系统崩了吗？是我的操作有问题吗？是Bug吗？

你去找开发，开发已经下班了。你只能把这个错误截图发到群里，留言：“这个500是什么意思？”

周一早上，开发回复：“哦，这个是后端代码报错了，我看看日志。”

你又问：“那400是什么？200又是什么？我经常看到这些数字，但一直没搞懂。”

开发说：“200是成功，400是你传的参数有问题，500是服务器挂了。”

你觉得这个解释太简单了，肯定没那么简单。

你开始回忆：你见过200但数据是错的，见过400但参数明明没问题，见过500但刷新一下就好了。

你突然意识到：状态码不是你想的那么简单。它们不只是数字，它们在“说话”——但你没听懂。

---

状态码在告诉你：问题出在谁身上

状态码不是“错误码”，是“系统在告诉你：我怎么了”。

你打电话给一个人。

• 电话接通了，对方说“喂”——这是200。连接成功了，系统在工作。
• 你拨错了号码，听到“您拨打的号码不存在”——这是400。你的请求有问题，系统处理不了。
• 你拨对了号码，但对方手机没电关机了——这是500。你的请求没问题，但系统自己出问题了。

200、400、500，本质上是在告诉你：问题是出在你身上（4xx），还是出在我身上（5xx）。

这是一个根本性的认知转变。

很多BA看到400，以为“系统报错了”。但400不是“系统错了”，是“你错了”——你传的参数不对、格式不对、没权限。

很多BA看到500，以为“我操作有问题”。但500不是“你错了”，是“我错了”——系统内部崩了、代码报错了、数据库连不上了。

区分“谁错了”，是理解状态码的第一步。

• 2xx：都没错，接口调通了
• 4xx：客户端错了，你要改
• 5xx：服务端错了，开发要修

但200只代表“处理完了”，不代表“处理对了”。这是一个更深的坑——后面会讲。

---

餐厅点餐类比：状态码的三个家族

我用“餐厅点餐”这个类比，把状态码的三个家族讲清楚。

2xx：一切正常，菜上了

你去餐厅，点了一份宫保鸡丁。

服务员说：“好的，马上做。”过了一会儿，菜端上来了。

这就是2xx。请求被接收了、处理了、返回了。

200 OK：菜端上来了，一切正常。

201 Created：你不仅点了菜，还办了一张会员卡。系统创建了新资源。

204 No Content：你问服务员“还有没有纸巾”，他说“有”，但没有给你什么东西。请求成功了，但没有返回数据。

---

4xx：你点错了，我不做

你去餐厅，点了一份“红烧狮子头”。

服务员说：“不好意思，我们没有这道菜。”

这就是4xx。你的请求有问题，服务端没法处理。

状态码	含义	场景
400 Bad Request	请求格式错误	参数缺失、JSON格式不对
401 Unauthorized	未登录	没登录或登录过期
403 Forbidden	无权限	登录了但没权限访问
404 Not Found	资源不存在	接口地址写错了
422 Unprocessable Entity	业务校验不通过	库存不足、手机号已注册

---

5xx：你的点单没问题，但我做不了

你点了一份宫保鸡丁，菜单上有，钱也付了。

但后厨着火了（代码报错），冰箱坏了（数据库挂了），厨师罢工了（服务崩溃）。

服务员说：“不好意思，系统出了点问题，您稍后再试。”

这就是5xx。你的请求没问题，但服务端自己出问题了。

状态码	含义	场景
500 Internal Server Error	服务端内部错误	代码报错、空指针
502 Bad Gateway	网关收到无效响应	下游服务挂了
503 Service Unavailable	服务不可用	过载、维护中
504 Gateway Timeout	网关超时	下游服务响应太慢

---

关键认知：200不代表“业务正确”

这是BA最容易掉进去的坑。

200只代表“系统处理完了你的请求”，不代表“处理结果是你想要的”。

你点了一份宫保鸡丁，服务员端上来一盘番茄炒蛋。你还是收到了菜（200），但这不是你要的。

在接口里，200可能返回了数据，但数据是错的、空的、旧的。

所以，判断接口“对不对”，不能只看状态码是不是200。要看业务返回码和业务数据。

很多接口会在响应体里再放一个业务状态码：

{
  "code": 0,
  "message": "success",
  "data": {...}
}

这里的code:0才是真正的“业务成功”。HTTP 200只是“接口调通了”。

---

两个致命错误：把状态码当Bug、分不清4xx和5xx的责任方

错误一：把状态码当Bug，不问场景

BA最常见的错误，是 “把状态码当Bug，不问原因”。

我见过一个真实案例。

测试人员报了一个Bug：“用户登录接口返回500。”

BA把Bug转给开发，开发查了日志，发现是数据库连接超时，修好了。

第二天，又报500。开发又修。

第三天，又报500。开发烦了，去查监控，发现是数据库连接池配置太小，并发一高就超时。这不是“Bug”，是“容量问题”。

如果BA在一开始就问一句：“500是每次都出现，还是偶尔出现？是只有这个接口还是所有接口？”开发就不会花三天时间修一个“假Bug”。

错误二：分不清4xx和5xx的责任方

另一个常见错误是：不知道4xx和5xx的责任方不同。

BA看到400，去找开发：“接口报错了。”

开发看了半天，说：“是你传的参数不对，userId是空的。”

BA说：“那你们怎么不做容错？”

开发说：“接口设计就是userId必填，你传空，我当然报400。这是调用方的问题，不是我的问题。”

如果BA知道400是“客户端错了”，她就会先去检查调用方（前端）传的参数对不对，而不是直接找后端开发。

---

状态码三问：快速判断问题和责任方

我送你一个模型，叫 “状态码三问”。

以后你遇到任何接口返回的状态码，用这三个问题去判断：

第一问：是2xx、4xx还是5xx？

• 2xx → 接口调通了，但业务不一定对。需要看业务状态码。
• 4xx → 调用方的问题。检查请求参数、权限、地址。
• 5xx → 服务端的问题。找后端开发看日志。

第二问：如果是4xx，具体是哪个？

状态码	下一步行动
400	检查必填参数、数据格式
401	重新登录，检查token
403	确认是否有权限访问
404	检查接口URL是否正确
422	检查业务规则（库存、状态等）

第三问：如果是5xx，是“崩了”还是“慢了”？

• 500 → 代码报错了，需要开发看日志
• 502/504 → 网关超时，可能是下游服务挂了或慢了
• 503 → 服务过载或重启中，可以稍后重试

---

补充：业务状态码 vs HTTP状态码

很多接口会在响应体里再放一个业务状态码，比如：

{
  "code": 1001,
  "message": "订单不存在",
  "data": null
}

这时候，HTTP状态码通常是200（接口调通了），但业务状态码告诉你“业务上没成功”。

BA需要区分：

• HTTP状态码 = 接口“通不通”
• 业务状态码 = 业务“成不成”

两者都要看，缺一个都可能被坑。

---

三个问题，检验你是否真懂状态码

下次你看到接口返回状态码时，用这三个问题自检：

问题1：我能区分“接口通了”和“业务成了”吗？

• 如果HTTP是200但业务没成，这是正常的（比如查询不到数据）
• 如果你把“200”当成“成功了”，你就会漏掉业务上的错误。

问题2：我知道4xx和5xx的责任方分别是谁吗？

• 4xx → 调用方（前端、调用系统）的问题
• 5xx → 服务端（后端）的问题
• 如果你找错人，既耽误时间，又显得不专业。

问题3：我能从状态码判断“接下来该做什么”吗？

• 400 → 改请求参数
• 401 → 重新登录
• 403 → 申请权限
• 500 → 找开发修
• 502 → 等一会儿再试，或找开发看下游
• 如果你不知道下一步做什么，说明你没理解这个状态码。

---

回头看：你已经走了多远

第一篇：为什么需要懂技术——因为不懂，连AI的错都看不出来。

第二篇：怎么学技术——类比、问问题、一句话讲清。

第三篇：为什么开发总怼你——把“说明”翻译成“定义”。

第四篇：技术世界在解决什么问题——存、传、算、显。

第五篇：点一下按钮发生了什么——微观请求之旅。

第六篇：怎么看懂系统架构图——宏观三段式。

第七篇：为什么电脑可以同时做多件事——操作系统的三个职责。

第八篇：前端 vs 后端，到底谁在干活？——前后端分工矩阵。

第九篇：为什么系统会“没反应”？——状态四象限。

第十篇：什么是API？——API三问。

第十一篇：为什么系统之间必须“说话”？——系统沟通五要素。

第十二篇：看懂接口文档——接口文档三定位。

第十三篇：为什么接口一改，系统会崩？——接口变更四步法。

第十四篇：GET vs POST——接口用途四象限。

第十五篇：为什么一个接口会“慢”？——耗时追踪三问。

第十六篇：状态码200/400/500——状态码三问。

文章	核心问题	你学会了什么
01	为什么需要懂技术？	不懂技术，连AI的错都看不出来
02	怎么学技术？	类比、问问题、一句话讲清
03	为什么开发总怼你？	把“说明”翻译成“定义”
04	技术到底在解决什么？	存-传-算-显
05	点一下按钮发生了什么？	微观请求之旅
06	怎么看懂系统架构图？	宏观三段式
07	为什么电脑可以同时做多件事？	操作系统的三个职责
08	前端和后端谁干什么？	前后端分工矩阵
09	为什么系统会“没反应”？	状态四象限
10	什么是API？	API三问
11	为什么系统之间必须“说话”？	系统沟通五要素
12	看懂接口文档	接口文档三定位
13	为什么接口一改，系统会崩？	接口变更四步法
14	GET vs POST	接口用途四象限
15	为什么接口会“慢”？	耗时追踪三问
16	状态码200/400/500	状态码三问

---

下一篇文章，我们聊一个设计层面的问题：一个接口设计得好不好，怎么判断？

你会发现，好的接口不是“能跑通”，而是“别人用起来不费劲”。

---

状态码是系统在跟你说话。

200说：“我收到了，处理了。” 4xx说：“你给的东西不对，我处理不了。” 5xx说：“你给的东西对，但我自己出问题了。”

当你听懂这些话，你就不会再对着500发呆，也不会再因为400去找后端开发吵架。

---

今日行动：

找一个你们系统正在使用的接口，用“状态码三问”分析一下它的返回：

1. 这个接口可能返回哪些HTTP状态码？
2. 每个状态码对应的责任方是谁？
3. 接口返回200时，还需要看业务状态码吗？

把分析结果发到评论区，我会选出3个典型案例，在后续文章中专门分析。

---

👉 还没关注的，点个关注，每天一篇，60天打通BA技术任督二脉。

PS：如果你也曾经被500吓到过，把这篇文章转给那个和你一样困惑的BA朋友。

---

【知识卡片】

状态码三大家族

2xx = 成功（接口通了） 4xx = 客户端错了（你改） 5xx = 服务端错了（我修）

常见状态码速查

状态码	含义	谁的责任
200	成功	-
400	参数错误	调用方
401	未登录	调用方
403	无权限	调用方
404	地址不存在	调用方
500	服务端错误	服务端
502/504	网关超时	服务端
503	服务不可用	服务端

HTTP状态码 vs 业务状态码

HTTP状态码 = 接口通不通 业务状态码 = 业务成不成 两者都要看。