HTTP 常见状态码有哪些？401、403 和 502、503、504 怎么区分？

知识点详解：把状态码放回请求链路中

分类有用，但不能直接当责任划分

假设客户端经过网关访问应用，应用又查询数据库。

请求可能在网关就被拒绝，也可能进入应用后失败。客户端拿到的状态码描述响应结果，却没有自动附带完整根因。

比如请求参数不符合要求，可以是 400；但参数之所以异常，也可能来自前端代码错误。应用返回 500，也可能由错误配置、依赖失败或程序异常触发。

所以，“4xx 都是用户错，5xx 都是后端程序员错”不是技术定义。MDN 状态码总览可以用于查类别，但工程定位还要带上下文。

401 和 403，差在响应希望表达什么

假设访问资料接口时没有提供有效凭证，服务端通过 401 表示认证条件没有满足。依据 RFC 9110，应提供适用的 WWW-Authenticate 挑战信息，而不只是随手写一段“未授权”文字。

如果请求已经被理解，却被访问策略拒绝，可以返回 403。常见情况是凭证对应用户不能查看这份资源；不过，拒绝也可能与凭证无关，例如其他访问限制。

因此，“401 没登录，403 已登录”只能当粗略例子，不是完整定义。不要从 403 反推认证一定成功，也不要让前端反复用同一凭证重试一个不会放行的请求。

服务端还可能为避免泄露资源是否存在，选择 404。前端不能把这些语义直接当成枚举内部数据的手段。

502、503、504，不能一起叫“服务器崩了”

先看 502。网关需要上游帮助完成请求，却收到无效响应，这属于网关角色相关的失败。上游连接、协议或响应问题是排查方向，具体代理怎样映射底层错误，要查产品配置和日志。

503 则表示当前暂时不能处理，例如过载或计划维护。它可以由应用或中间层返回，并不要求一定有网关等上游超时。

504 需要识别“等待上游及时响应”这个关系。是网关自己的等待边界到了，不是自动证明数据库超时，更不是自动证明应用进程已经退出。

MDN 502、503与504分别保留了这些区别。

504 为什么不能直接触发重复写入？

假设网关最多等 3 秒，后端写入用了 4 秒。

第 3 秒网关可能已经向客户端返回 504；第 4 秒后端仍可能完成写入。客户端没有拿到及时响应，与后端没有执行，是两个不同结论。

如果客户端立即再提交一次，没有幂等机制，就可能重复执行。这也是为什么写操作需要请求身份、去重和状态查询等设计，而不是只按某几个错误码统一重试。

同样，把网关超时从 3 秒改到 30 秒，不是根因修复。还要看业务延迟、其他层截止时间和资源占用。

成功状态，也需要和业务结果对上

200 表示相应请求成功处理，但接口还应按约定提供正确响应内容。把所有业务失败都包进 HTTP 200，会让通用网关、监控和客户端策略失去一部分判断依据。

201 表达资源已创建，202 表达已接受处理但没有承诺处理完成。假设异步任务只排进队列，返回 202 比直接宣布最终成功更符合这条边界。

204 不包含响应内容，也不能一边说“无内容”，一边要求客户端解析必须存在的 JSON。具体接口选择要和操作语义一致，不能为了统一外观把状态全部抹平。

面试里怎么讲排查顺序才具体？

先找这次请求的链路标识，确认哪一层真正生成响应。

再对照各层耗时、错误日志、上游状态和超时配置：504 看哪一段等待到期，503 看负载与维护/限流策略，502 看实际收到的上游响应和代理映射。

最后再决定客户端动作。允许重试的操作，也应有限次、退避、尊重总截止时间；有 Retry-After 时按适用语义处理。429 的限流响应，也不能和 503 直接混为同一根因。

这比背很多数字更有用：面试官换一个链路，我们仍能沿返回来源重新判断。

面试官继续追问

只看到 500，可以确定是数据库故障吗？

不能。500 是服务端意外失败的响应类别，数据库只是可能依赖之一，要查具体异常和调用链。

403 应该自动刷新 token 吗？

不能统一这样做。先按接口认证与权限约定判断；同一份权限不足的身份换一张同等凭证，也不会凭空获得权限。

202 就代表任务之后一定成功吗？

不代表。它表达已接受，后续状态、失败原因和查询方式还要定义。

面试速记卡

• 状态码：描述本次 HTTP 处理语义，不直接裁定故障责任。
• 401：缺少有效认证凭证，按规范提供认证挑战。
• 403：理解但拒绝，不保证重新登录可以解决。
• 502 / 503 / 504：无效上游响应 / 暂时无法服务 / 等上游超时。
• 重试：先查幂等与执行状态，超时不证明写入未发生。