想象你走进一家餐厅点餐。你说出需求（请求），后厨一通忙活（处理），服务员出来给你回话（响应）。但回话是有“暗语”的：有的表示“菜已上齐”，有的表示“这菜对面才有，您得挪个座位”，还有的表示“我们厨房出状况了”。你不需要听懂六十多种细节，只要听出话里的“方向”就能明白下一步该干嘛。 HTTP状态码，就是互联网世界里服务生的回话暗语——一个藏在响应消息里的三位数字。它的神奇之处在于：百位数字直接告诉你“这事儿属于哪一类”。1开头是“稍等，正在备菜”，2开头是“成了”，3开头是“请换个地方”，4开头是“您的请求有问题”，5开头是“我们的服务出了问题”。 这篇文里，我们将跟着餐厅的“五格回话表”把状态码体系拆开看：先学五类分类，再逐个认领 200、301、404、502 这些常客，把 301 和 302、401 和 403、502 和 504 这些“双胞胎”认清楚，最后把状态码写成一份团队 API 的服务手册。读完后你会发现，状态码不是冷冰冰的报错数字，而是让前端、后端、网关、监控四方快速对齐的公共语言。

岗位关联

对 AI 从业者而言，状态码是你调试模型接口、排查服务异常时最先看到的“体检报告”。看懂它，你可以在同事还在翻日志时，一眼定位问题出在客户端一侧还是服务端一侧。

目录
  1. 可视化演示
  2. 状态码概览
  3. 成功类2xx
  4. 重定向类3xx
  5. 客户端错误4xx
  6. 服务端错误5xx
  7. 易混码辨析
  8. RESTful指南
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态演示HTTP状态码体系的核心机制，通过总览/传输/转换/输出四种模式展示关键概念与交互流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

HTTP状态码体系：五类状态 五类状态码分类体系 2xx 成功与 3xx 重定向 核心机制可视化 HTTP状态码体系整体架构与关键组件

状态码概览

餐厅后厨的墙上贴着一张《回话五格表》：第一格写“正在做”，第二格写“菜已上桌”，第三格写“请换座位”，第四格写“您说错了”，第五格写“我们厨房出问题了”。不管顾客问什么，服务员看一眼情况，先把回话归到某一格，再报具体细节。这套规矩保证了：哪怕换了新服务员，回话风格依然统一、不会乱套。

HTTP 协议的做法如出一辙。服务器处理完请求后，会在响应消息的第一行——也就是状态行里，放上一个三位数字的“回话暗语”：状态码（Status Code）。响应消息由三部分构成：状态行（服务员开口的第一句话）、响应头（话里的语气和附加说明）、响应体（端上来的“菜”）。状态码就藏在状态行里，告诉客户端这次的请求结果属于哪一类。

三位数字各司其职：百位决定大类，后两位负责细分。百位是 1 表示信息响应，2 表示成功，3 表示重定向，4 表示客户端错误，5 表示服务端错误。所有标准状态码都落在 100 到 599 的区间内，后两位的语义由 RFC 9110 等协议规范定义。这样一个“先归类、再细化”的设计，让全世界开发者看到任何状态码都能立刻把握大方向。

所以，当你面对任何一个状态码，第一反应应该是看百位：2 开头松一口气，4 开头检查自己的请求，5 开头抄起日志去查后端。就像服务员先归格再报细节，你排障时也应该“先归类、再定位”，这能帮你节省大量时间。

类别(c)=⌊c100⌋,100≤c≤599\displaystyle \text{类别}(c) = \left\lfloor \frac{c}{100} \right\rfloor, \quad 100 \le c \le 599
这个公式的意思是：状态码只提取百位数字，百位是几，就归到第几类。
  1. 状态码取值状态码是 HTTP 响应中那三位数字，取值范围从 100 到 599。
    c∈[100,599]c \in [100, 599]
  2. 提取百位把状态码除以 100 后向下取整，得到百位数字，例如 404 除以 100 得 4。
    ⌊404100⌋=4\lfloor \tfrac{404}{100} \rfloor = 4
  3. 类别映射百位数字决定请求结果的“大类”：2 是成功、3 是重定向、4 是客户端问题、5 是服务端问题。
    百位=4⇒客户端错误\text{百位} = 4 \Rightarrow \text{客户端错误}

成功类2xx

2xx 是餐厅里最动听的回答——服务员端着菜走来，笑着说：“您的菜已经上齐了！”没有追问、没有转折、没有“但是”，一切刚刚好。对于等待中的顾客而言，这句话意味着之前的沟通、后厨的忙碌、传菜的等待全部值了。

在网络世界里，2xx 表示请求已被服务器成功接收、理解并处理。它不是一个码，而是一族码，日常开发中最常遇见的是 200、201、204 三个。它们都代表“成功”，但成功的“程度”和“后续动作”不同——这正是 HTTP 状态码的魅力：用最少的数字表达最精确的语义，让调用方一看便知下一步该怎么走。

200 OK 是“全家桶”级的成功，GET 查询用户信息、PUT 更新资源，响应体里装的就是你要的数据。201 Created 常用于 POST 创建场景，资源已经在服务器上诞生，响应头 Location 会指向新资源的地址。204 No Content 则像“无声的点头”，DELETE 删除成功后用 204 告诉客户端“成了，但不用给我看任何东西”，既省流量又让代码更清爽。

下次接口返回 2xx 时，别急着高兴，先看一眼具体是哪一个：200 读取返回的数据，201 去 Location 找新资源，204 直接收工。正如餐厅里“上菜”“上新菜”“不用再上东西”各有各的服务流程，HTTP 状态码也把成功场景分得明明白白。

语义(c)={OK,c=200Created,c=201No Content,c=204\displaystyle \text{语义}(c) = \begin{cases} \text{OK}, & c=200 \\ \text{Created}, & c=201 \\ \text{No Content}, & c=204 \end{cases}
三个码都代表成功，区别只在“成功之后有没有内容要告诉你”。
  1. 200 OK最通用的成功码，响应体携带数据，GET 和 PUT 常用。
    GET⇒200+Body\text{GET} \Rightarrow 200 + \text{Body}
  2. 201 CreatedPOST 创建资源成功，响应头 Location 给出新资源地址。
    POST⇒201+Location\text{POST} \Rightarrow 201 + \text{Location}
  3. 204 No ContentDELETE 成功且没有响应体，客户端无需解析额外内容。
    DELETE⇒204+∅\text{DELETE} \Rightarrow 204 + \emptyset

重定向类3xx

想象一下：你爱吃的那道糖醋里脊，这家店突然不做了。服务员礼貌地告诉你：“这道菜我们店已经不卖了，隔壁老王快餐店有一样的招牌菜，您去那边吧。”这时你面临一个选择：以后都去隔壁？还是这次先尝尝、下次再回来碰运气？3xx 状态码就是在帮你解决这个“去哪儿”的问题。

3xx 表示“要完成请求，你需要去另一个地址”。最常遇见的三个码是 301、302 和 304。它们都用 HTTP 响应头里的 Location 字段告诉浏览器“新地址在哪”，但语义各有侧重，选错会直接影响搜索引擎收录和用户体验。

301 Moved Permanently 是“永久搬家”：旧地址彻底作废，浏览器和搜索引擎会直接更新索引，以后都走新地址。302 Found 是“临时换桌”：这次先跳过去，下次请求还访问原地址。304 Not Modified 则是个“省钱小能手”：服务器检查后发现资源没变化，直接告诉你“你缓存的版本就是最新的”，于是响应体为空，客户端用本地缓存即可。此外，307 和 308 是 302 和 301 的“保守版”，它们会保留请求方法和请求体，避免 POST 被悄悄改成 GET。

3xx 是互联网的“导购员”，礼貌地把流量引到正确的地方。前端遇到 301 要赶紧更新链接和书签，遇到 302 则不必大动干戈——正如“搬家”和“串门”虽然都是出门，但一个要改通讯录，一个不用。

URL 是否更新={是（永久）,c=301否（临时）,c=302\displaystyle \text{URL 是否更新} = \begin{cases} \text{是（永久）}, & c = 301 \\ \text{否（临时）}, & c = 302 \end{cases}
一句话：301 是“搬家了、老地址作废”，302 是“今天临时换个门，明天还回来”。
  1. 301 永久旧 URL 作废，客户端和搜索引擎更新缓存中的地址。
    301⇒URLnew301 \Rightarrow \text{URL}_{\text{new}}
  2. 302 临时本次请求临时跳转，后续仍用原 URL。
    302⇒URLold302 \Rightarrow \text{URL}_{\text{old}}
  3. 304 缓存服务器表示“你缓存的就是最新版”，响应体为空。
    304⇒∅body+Cache304 \Rightarrow \emptyset_{\text{body}} + \text{Cache}

客户端错误4xx

4xx 是服务员皱着眉头的表情：“您说的这道菜，我们菜单上真没有；而且您还没说清楚菜名，会员卡也没带。”问题的根源在顾客，不在后厨。这个大类里的状态码，全部表示“请求本身有问题”，服务器只是如实指出了问题所在。

4xx 家族庞大，日常开发中出现频率极高。它们看似都是“红叉叉”，但细分语义完全不同，排障方向也天差地别：400 Bad Request 表示请求格式错误，JSON 解析失败、参数缺漏都算；401 Unauthorized 表示未认证，服务器不知道你是谁，请带上登录凭证（Token）再来；403 Forbidden 表示已认证但没有权限，服务器认识你，但你不被允许访问该资源；404 Not Found 表示资源不存在，URL 写错或资源已删除；429 Too Many Requests 表示请求太频繁，触发了限流保护。

遇到 4xx，第一反应应该是检查自己的请求：URL 对不对、参数全不全、Token 带了没、权限够不够。顾客的问题不能怪后厨——同样的道理，把 4xx 全部当成“服务器错误”去提工单，只会浪费所有人的时间。

访问结果={未认证→401无权限→403不存在→404\displaystyle \text{访问结果} = \begin{cases} \text{未认证} \to 401 \\ \text{无权限} \to 403 \\ \text{不存在} \to 404 \end{cases}
401 是“你是谁？”，403 是“知道你是谁，但你不配”。一个管进门，一个管房间里哪些位置能坐。
  1. 401 未认证请求缺少有效凭证，服务器先要验明身份。
    Request∧¬Auth⇒401\text{Request} \wedge \neg \text{Auth} \Rightarrow 401
  2. 403 无权限身份有效但权限不足，服务器拒绝访问。
    Auth∧¬Perm⇒403\text{Auth} \wedge \neg \text{Perm} \Rightarrow 403
  3. 404 不存在请求的 URI 上没有对应的资源。
    URI∉Resources⇒404\text{URI} \notin \text{Resources} \Rightarrow 404

服务端错误5xx

5xx 是服务员满头大汗地道歉：“是我们的错！厨房炸了、传菜电梯堵了、采购的食材没送到……”这时顾客完全没错，问题出在餐厅自身。5xx 状态码正是用来表达这层意思的：你的请求没问题，是服务器或它依赖的上游出了状况。

常见 5xx 码有四个。500 Internal Server Error 是“厨房自己炸了”——服务器内部抛出未捕获异常、数据库连接失败等；502 Bad Gateway 是“传菜电梯送上来的不是菜”——网关或代理收到了上游服务器的非法响应；503 Service Unavailable 是“餐厅今天打烊”——服务过载或处于停机维护状态，此时可配合 Retry-After 响应头告知客户端多久后再试；504 Gateway Timeout 是“让后厨做菜，等了半天没端上来”——网关等待上游响应超时。

5xx 是运维的“噩梦方向标”：500 查代码堆栈，502 查上游服务和网关配置，503 等一等或扩容，504 查上游响应速度和超时阈值。每一种“厨房灾难”都有对应的补救办法，状态码就是最直接的破案线索。

故障点={应用内部异常→500上游非法响应→502过载或维护→503上游超时→504\displaystyle \text{故障点} = \begin{cases} \text{应用内部异常} \to 500 \\ \text{上游非法响应} \to 502 \\ \text{过载或维护} \to 503 \\ \text{上游超时} \to 504 \end{cases}
500 是“厨房自己炸了”，502 是“传菜电梯送上来一盘不是菜的东西”，503 是“餐厅打烊了”，504 是“后厨做菜半天没端上来”。
  1. 500 内部错误服务器自身的代码或依赖出问题，未捕获的异常直接抛出。
    Exceptionuncaught⇒500\text{Exception}_{\text{uncaught}} \Rightarrow 500
  2. 502 网关错误网关收到上游服务器的非法响应，无法转发给客户端。
    Upstreaminvalid⇒502\text{Upstream}_{\text{invalid}} \Rightarrow 502
  3. 503 不可用服务过载或维护中，可附带 Retry-After 头告知重试时间。
    Overload⇒503+Retry-After\text{Overload} \Rightarrow 503 + \text{Retry-After}
  4. 504 网关超时网关等待上游响应超过时间阈值。
    Twait>Tlimit⇒504T_{\text{wait}} > T_{\text{limit}} \Rightarrow 504

易混码辨析

有些状态码就像双胞胎，长得几乎一样，脾气却完全不同。认错“双胞胎”，排查方向就会整个跑偏，就像把“邻家串门”当成“搬家”，结果白跑一趟还改了通讯录。这一节我们专门给三组最经典的“双胞胎”做区分。

第一组：301 vs 302。区别在于“永久性”。301 告诉浏览器“以后都别再访问旧地址了”，浏览器会更新书签和缓存；302 说“这次先跳过去，下次还来原地址”。第二组：401 vs 403。区别在于“认证”和“授权”两个阶段。401 是“你没有身份证明”，通常缺 Token；403 是“你有身份证明但没资格”，Token 带了却不在访问白名单里。第三组：502 vs 504。区别在于“响应内容”和“响应时间”。502 是“上游活着但说胡话”，返回了非法响应；504 是“上游压根不理你”，等了太久也没等到响应。

双胞胎也好认，关键是找到“尺子”：用“永久/临时”量重定向，用“身份/权限”量访问控制，用“内容/时间”量网关故障。三把尺子在手，任何一对“双胞胎”都不会再认错。

易混码={301 永久↔302 临时401 你是谁↔403 你不行502 说胡话↔504 不理你\displaystyle \text{易混码} = \begin{cases} 301\ \text{永久} \leftrightarrow 302\ \text{临时} \\ 401\ \text{你是谁} \leftrightarrow 403\ \text{你不行} \\ 502\ \text{说胡话} \leftrightarrow 504\ \text{不理你} \end{cases}
用场景记：搬家（301）、串门（302）、进门查证（401）、进包间查权限（403）、传菜电梯故障（502）、后厨超时（504）。
  1. 301 vs 302比较地址的“永久性”，决定是否更新客户端记录。
    Permanent(301)=True, Permanent(302)=False\text{Permanent}(301) = \text{True}, \ \text{Permanent}(302) = \text{False}
  2. 401 vs 403区分“认证”与“授权”两个阶段，一个缺证明、一个没资格。
    Authed(401)=False, Authed(403)=True\text{Authed}(401) = \text{False}, \ \text{Authed}(403) = \text{True}
  3. 502 vs 504区分“响应内容非法”与“响应时间超限”。
    Invalid(502)=True, Timeout(504)=True\text{Invalid}(502) = \text{True}, \ \text{Timeout}(504) = \text{True}

RESTful指南

一家好餐厅会有一本《服务手册》：什么情况说什么话、由谁负责、如何补救，全都有章可循。RESTful API 设计也需要这样一本“状态码手册”。状态码不是随手填的数字，而是 API 与调用方之间的服务契约——选对了，双方都省心。

RESTful 设计的核心是“资源”与“语义”：每个 URL 代表一种资源，HTTP 方法表示对该资源的操作，状态码则如实报告操作结果。两者必须匹配：语义匹配上，GET 成功应返回 200、POST 创建成功应返回 201、DELETE 删除成功应返回 204；资源找不到返回 404，参数不合法返回 400。错误响应体也要规范：状态码之外，响应体应给出结构化错误信息，例如 {"code": "USER_NOT_FOUND", "message": "用户不存在"}，让客户端不用靠猜状态码来定位原因。

幂等设计同样关键：GET、PUT、DELETE 是幂等的，重复执行结果一致，失败后可以放心重试；POST 不幂等，重复提交会创建多个资源，因此必须用 201 明确告知“新资源已生成”。配合 429 限流和 503 过载保护，整个系统在异常流量下依然能优雅地降级，而不是直接崩溃。

其中 \( M \) 为 HTTP 方法，\( R \) 为资源，Semantic 表示“方法+资源”的语义组合。

把状态码规范写进团队的 API 文档，就像给餐厅立下服务手册。调用方看到状态码就知道下一步该做什么，监控系统也能据此快速告警，你的 API 才算真正做到了“好服务，会说人话”。

Code(M,R)=Semantic(M,R)\displaystyle \text{Code}(M, R) = \text{Semantic}(M, R)
状态码不是随便选的，它由“你用什么方法、操作什么资源”共同决定，就像服务员的服务手册会写明“什么菜配什么餐具”。
  1. 方法 MGET/POST/PUT/DELETE 定义了操作类型，是“动词”。
    M∈{GET,POST,PUT,DELETE}M \in \{\text{GET}, \text{POST}, \text{PUT}, \text{DELETE}\}
  2. 资源 RURL 指向的具体对象，是“名词”。
    R=URItargetR = \text{URI}_{\text{target}}
  3. 语义联合方法与资源的组合共同决定返回哪个状态码。
    GET+R存在⇒200;POST⇒201;DELETE⇒204\text{GET} + R_{\text{存在}} \Rightarrow 200; \quad \text{POST} \Rightarrow 201; \quad \text{DELETE} \Rightarrow 204

AI 应用场景

AI模型推理服务的健康监控与故障定位

阶段：模型部署与运维（MLOps）

解决的问题：AI 模型推理服务本质上也是 HTTP 服务，客户端把文本或图片发送给模型，模型处理完把结果返回。过去排查推理服务异常，要从日志、监控、网关三层反复翻找，效率低下。掌握了状态码体系后，团队可以用状态码直接区分故障层：500 定位到模型代码异常，502/504 定位到 GPU 推理服务崩溃或超时，429 说明推理实例需要扩容。

具体案例：某 AI 公司上线了一款对话式大模型服务，高峰期网关日志涌现大量 504。运维团队看到 504 立刻判断是推理服务响应时间超过了网关超时阈值，随后检查 GPU 推理服务的队列长度，发现并发请求过多导致单次推理被拖长。团队优化了推理并发上限、调大网关超时，并在过载时返回 503 配合 Retry-After 头让客户端礼貌重试，系统恢复平稳。

AI Agent 工具调用的自动纠错与重试

阶段：Agent 工具调用与 RAG 检索

解决的问题：AI Agent 在运行中需要调用外部工具，比如搜索知识库、查询天气、调用企业 ERP 接口。工具返回的 HTTP 状态码是 Agent 判断下一步动作的关键信号：401 说明工具需要新的 API Key，Agent 应暂停调用并通知管理员；429 说明触发了限流，Agent 应执行指数退避重试；404 说明工具 URL 配置错误，Agent 应停止重试并切换到备用工具。

具体案例：一个企业级 RAG 问答机器人在检索内部知识库时频繁返回 403，开发团队一开始以为是 API Key 失效，反复轮换密钥无果。后来检查响应体中的结构化错误码，发现是机器人身份（Service Account）缺少知识库某个分类的读取权限。调整权限策略后，403 消失，问答准确率随之恢复。状态码加结构化错误体，让 AI 应用能自助定位权限问题。

Python 演示

python51 行
# -*- coding: utf-8 -*-"""HTTP status code classifier and RESTful advice generator."""  class HTTPStatus:    def __init__(self, code):        if not 100 <= code <= 599:            raise ValueError("invalid status code: %d" % code)        self.code = code     def category(self):        part = self.code // 100        return {            1: "information",            2: "success",            3: "redirect",            4: "client_error",            5: "server_error",        }[part]     def advice(self):        table = {            200: "GET ok, body contains result",            201: "POST created, Location points to new resource",            204: "DELETE ok, no content returned",            301: "permanent redirect, update old link",            302: "temporary redirect, keep original link",            304: "not modified, use local cache",            400: "bad request, check params or body",            401: "unauthorized, add auth token",            403: "forbidden, no permission",            404: "resource not found, check URL",            429: "too many requests, backoff and retry",            500: "internal server error, check logs",            502: "bad gateway, upstream gave invalid response",            503: "service unavailable, overload or maintain",            504: "gateway timeout, upstream too slow",        }        return table.get(self.code, "see RFC 9110")  def main():    codes = [200, 201, 204, 301, 302, 400, 401, 403, 404, 429,             500, 502, 503, 504]    for c in codes:        s = HTTPStatus(c)        print("[%d] %-14s -> %s" % (s.code, s.category(), s.advice()))  if __name__ == "__main__":    main()
目的：用一个小工具把常见 HTTP 状态码归类并给出 RESTful 语义建议，帮你建立“先看百位、再看细节”的排障直觉。
  1. if not 100 <= code <= 599:状态码必须是三位数范围，非法输入直接拦截，避免调用方传出“两位数”闹乌龙。
  2. part = self.code // 100用整除提取百位数字，一句话实现“先归类再定位”的排障思路。
  3. table = {把常用状态码的语义和建议收进一张映射表，就像餐厅的《服务手册》。
  4. print("[%d] %-14s -> %s" % (s.code, s.category(), s.advice()))格式化输出三大信息：原始状态码、类别、RESTful 建议。
  5. if __name__ == "__main__":标准入口保护，让模块被 import 时不会自动执行，只有运行时才演示。

常见误区

误区我看到接口返回 400、401、403、404，第一反应都是“我的代码写错了”，然后疯狂加日志、看参数、怀疑人生。

正解4xx 虽然都属于客户端错误，但细分语义完全不同：400 是格式不对、401 是没登录、403 是没权限、404 是不存在。就像服务员说“您说错话”和“您没带会员卡”和“您没资格进包间”完全是三码事。排查时先分清是哪一种“顾客问题”：格式问题改请求体，认证问题加 Token，权限问题找管理员，不存在问题检查 URL。

为何常见：初学者习惯把“非 2xx”统一归为“失败”，忽略了状态码本身携带的细粒度诊断信息。这就像把所有餐厅回话都听成“不行”，却分不清是“没菜”还是“没资格”。

误区301 和 302 不都是跳转吗？反正都能跳到新页面，随便用哪个都行。

正解差别巨大。301 是永久重定向，浏览器和搜索引擎会更新索引，旧链接作废；302 是临时跳转，不更新索引。如果把永久迁移的网址配成 302，流量会一直先访问旧地址再跳到新地址，白白增加一跳延迟，在 SEO 里也会被搜索引擎降权。正确做法：确认旧地址不再使用，就配 301；只是临时活动页，就配 302。

为何常见：肉眼看到的效果都是“页面跳转过去了”，没有意识到底层语义差异对缓存更新和搜索引擎收录的长期影响。

误区502 和 504 都是网关报错，报错页面长得都差不多，不用区分，反正是服务器的事。

正解502 是网关拿到了非法响应，意思是上游进程活着但返回了错误内容；504 是网关等了太久没等到响应，意思是上游根本没理你。排查方向完全不同：502 要查上游进程是否崩溃、SSL 配置是否错误、负载均衡是否把请求转发到了错误端口；504 要查上游响应速度、数据库慢查询、网关超时配置。混为一谈等于对着“传菜电梯故障”和“后厨出菜超时”用同一套维修方案。

为何常见：两者都出现在网关层，报错页面看起来也像，容易当成同一种问题。实际只需要记住“内容”和“时间”这一把尺子。

误区后端业务错误太多了，状态码不够用。我干脆用 200 返回业务错误码，比如 `{"code": -1, "message": "余额不足"}`，这样前端统一处理更方便。

正解滥用 200 会把 HTTP 的公共语义彻底搞坏。客户端、网关、监控系统都依赖状态码做缓存、重试、告警，你返回 200 时它们会以为一切正常，业务错误就会被静默吞掉。正确做法是：状态码只表达传输层的语义（成功/重定向/客户端错/服务端错），业务细节放进响应体的结构化错误码，例如 {"code": "BALANCE_NOT_ENOUGH", "message": "余额不足"}。

为何常见：只站在前后端联调的视角看问题，忽略了状态码是客户端、网关、监控三方共用的公共协议。就像餐厅服务员自创了一套只有自己听得懂的暗语，客人全懵了。

误区请求太频繁时，返回 429 和 503 都是“暂时不行了”，随便选一个就行。

正解429 Too Many Requests 是“你太快了，请慢点”，属于客户端行为触发的限流，客户端应该退避重试；503 Service Unavailable 是“服务暂时不可用”，属于服务端容量问题，客户端应该等待 Retry-After 头指示的时间再试。用错会导致灾难：把 429 当成 503 返回，客户端就不知道是自己的问题，无限重试反而加重服务负担；把 503 当成 429 返回，客户端疯狂退避，服务恢复后流量却迟迟上不来。

为何常见：两个码都带“请求暂时不能被处理”的意思，但判断标准是“谁的错”——是用户太快，还是服务器太弱。抓住这一条，就不会再混。

面试题

Q1. HTTP 状态码 200 表示什么？

单选题 · easy

  • A.请求成功，响应体包含结果← 正确答案
  • B.请求被重定向
  • C.客户端请求有误
  • D.服务器内部错误

答案：A。200 OK 表示请求被成功处理，响应体里装的就是你要的数据。类比餐厅服务员说“菜已上齐”；重定向是 3xx，客户端错误是 4xx，服务器错误是 5xx。

Q2. 301 和 302 的核心区别是什么？

单选题 · easy

  • A.前者是永久重定向，后者是临时重定向← 正确答案
  • B.前者是客户端错误，后者是服务端错误
  • C.前者无响应体，后者有响应体
  • D.前者只适用于 GET，后者只适用于 POST

答案：A。301 是“永久搬家”，旧地址作废，浏览器和搜索引擎会更新索引；302 是“临时换桌”，这次先跳、下次还来。两者都是 3xx 重定向，与请求方法无关，B、C、D 都不正确。

Q3. 以下哪些属于 4xx 客户端错误？

多选题 · mid

  • A.400 Bad Request← 正确答案
  • B.403 Forbidden← 正确答案
  • C.500 Internal Server Error
  • D.502 Bad Gateway

答案：AB。400 表示请求格式错误，403 表示无权限，都是“顾客的问题”，属于 4xx。500 是服务端内部错误，502 是网关收到上游非法响应，两者都属于 5xx 服务端错误。

Q4. 一个未登录的用户访问需要登录的接口，服务器最应返回？

单选题 · mid

  • A.400
  • B.401← 正确答案
  • C.403
  • D.404

答案：B。未登录是“没有身份证明”，对应 401 Unauthorized，应引导用户携带登录凭证重试。403 是已登录但没有权限；400 是请求格式错误；404 是资源不存在。就像没有会员卡进餐厅，服务员会先要求“出示证件”。

Q5. 关于 502 和 504，下列说法正确的有？

多选题 · hard

  • A.502 表示网关收到上游服务器的非法响应← 正确答案
  • B.504 表示网关等待上游响应超时← 正确答案
  • C.两者都属于 5xx 服务端错误← 正确答案
  • D.502 表示客户端请求格式错误

答案：ABC。502 和 504 都是网关层的 5xx 错误。502 是“上游说胡话”，返回了非法响应；504 是“上游不理你”，等待超时。D 是典型的 4xx 语义，与网关错误无关。

Q6. POST 创建资源成功后，最合适的返回状态码是？

单选题 · mid

  • A.200
  • B.201← 正确答案
  • C.204
  • D.302

答案：B。POST 创建资源应返回 201 Created，响应头 Location 指向新资源地址。200 用于 GET 查询成功；204 用于 DELETE 删除成功且无内容返回；302 是临时重定向，与创建语义不符。就像新菜录入了菜单，服务员告诉你“菜已入册”。

Q7. 某个接口限制每个用户每秒最多 10 次请求，超出后应返回？

单选题 · mid

  • A.400
  • B.401
  • C.429← 正确答案
  • D.503

答案：C。429 Too Many Requests 专用于“客户端请求太频繁”，是客户端的错，客户端应退避重试。400 是格式错误，401 是未认证，503 是服务端过载或维护——503 是“厨房打烊”，而 429 是“您吃太快了，歇会儿”。

Q8. 关于 RESTful API 的状态码设计，推荐做法有？

多选题 · hard

  • A.GET 成功返回 200← 正确答案
  • B.DELETE 成功返回 204← 正确答案
  • C.参数校验失败返回 400← 正确答案
  • D.所有业务错误都返回 200，用响应体里的 code 区分

答案：ABC。A、B、C 都符合 RESTful 语义匹配原则。D 是典型反模式：滥用 200 会让客户端、网关、监控系统失去判断依据，业务错误被静默吞掉。正确的做法是状态码表达传输层语义，业务细节放进响应体的结构化错误码。