HTTP状态码全解析：分类语义与工程实践

一、HTTP状态码是什么

HTTP状态码是服务器响应客户端请求时返回的三位数字代码，用于概括本次请求的处理结果。它位于响应状态行中，形如 HTTP/1.1 200 OK：三位数字是机器判读的依据，其后的短语则是给人看的描述。

从规范演进来看，状态码最初由 RFC 2616 定义，该规范后来被拆分修订，HTTP/1.1 的语义目前主要由 RFC 7231 等文档承载；在此基础上，RFC 2518（WebDAV）、RFC 2817、RFC 2295、RFC 2774、RFC 4918 等规范对其做了扩展。状态码的官方注册表由互联网号码分配局（IANA）统一维护，任何新增状态码都需经过注册流程，这保证了全球互联互通时的语义一致性。

有两个容易被忽略的细节值得强调：

1. 首位数字决定类别。所有状态码的第一个数字代表响应的五种状态之一，同类之下再细分具体语义。
2. 消息短语只是“典型写法”。状态行中的短语是建议性文本，服务器可以返回任何可读的替代短语。客户端程序不应解析短语内容，而应只依据数字编码做逻辑判断。

此外，部分Web服务器实现会在响应正文或日志文档中使用带小数点的扩展子码（如 xxx.1、xxx.2）来提供更细粒度的错误线索，但这类子码只存在于应用层内容中，并不会取代线路上传输的标准三位状态码，通用客户端也无法感知它们。

二、五大类别总览

• 1xx：信息性响应，请求已接收，处理仍在继续；
• 2xx：成功，请求已被接收、理解并接受；
• 3xx：重定向，客户端需采取进一步动作才能完成请求；
• 4xx：客户端错误，请求本身存在语法错误或无法满足的条件；
• 5xx：服务器错误，请求合法但服务器在处理过程中出错。

三、1xx：信息性状态码

这一类响应是临时响应，只包含状态行和部分可选响应头，以空行结束，其后必然还会跟随一个终止性响应。由于 HTTP/1.0 协议未定义任何 1xx 状态码，除非处于实验条件，服务器不应对此类客户端发送 1xx 响应。

100 Continue：告知客户端“目前一切正常，可以继续发送”。典型场景是客户端要上传大体积请求体时，先携带 Expect: 100-continue 请求头“探路”；服务器若愿意接收则回以100，客户端再发送剩余数据；若服务器直接返回终态错误响应，客户端便可省去传输大请求体的开销。需要注意：服务器在请求处理完成后必须返回一个最终响应，100 只是过程信号。

101 Switching Protocols：服务器已理解客户端请求，并同意通过 Upgrade 消息头切换到不同的协议来完成请求；发送完本响应后的空行，服务器即在新协议上通信，典型例子是升级到WebSocket以获得双向实时通道。规范要求：只有切换协议确实带来好处时才应这么做，例如新协议能承载实时、同步的资源传输能力。

102 Processing：由WebDAV扩展引入，表示服务器已收到请求、处理将继续执行。用于耗时较长的批量操作，防止客户端在长时间等待中误判超时而断开连接。

四、2xx：成功状态码

这一类状态码代表请求已被服务器成功接收、理解并接受。

200 OK：最常见的成功码，请求所期望的响应头或数据体随本次响应返回。需要注意的是，在接口设计中不宜“一律200”：创建资源更推荐201，无实体返回的操作更推荐204，滥用200会丢失语义信息。

201 Created：请求已被实现，且有新资源依据请求建立，其URI通过 Location 响应头返回，适用于POST创建资源的场景。若资源无法及时建立（如需异步审核），应当返回202。

202 Accepted：服务器已接受请求但尚未处理，最终可能执行也可能被拒绝。适用于异步任务、消息队列削峰等场景。客户端应意识到“受理不等于成功”，需通过查询接口或回调确认最终结果。

204 No Content：处理成功但响应体为空，常用于删除成功、表单提交后无需返回内容等场景。

206 Partial Content：配合 Range 请求头实现分段下载与断点续传，响应体只包含资源的指定区间，视频拖动播放、大文件分片下载均依赖它。

五、3xx：重定向状态码

301 Moved Permanently：永久重定向，搜索引擎等客户端会更新指向旧地址的链接，适用于站点改版、地址迁移，浏览器通常会缓存该结果。

302 Found：临时重定向，本次请求改用新URI，但旧地址依然有效。

303 See Other：指示客户端用GET访问另一URI，常见于POST提交后跳转结果页，防止刷新导致重复提交。

304 Not Modified：协商缓存的产物。客户端携带 If-Modified-Since 或 If-None-Match 条件请求，资源未变化时服务器返回304且不带响应体，客户端直接使用本地缓存，可显著节省带宽。

307/308：分别是302/301的“严格方法”版本，重定向时保持原请求方法与请求体不变，避免方法被改写为GET带来的歧义。

六、4xx：客户端错误状态码

• 400 Bad Request：请求语法错误或参数无法解析，属“兜底”型错误，语义更具体时应优先选用更精确的状态码；
• 401 Unauthorized：未认证，请求需要身份凭证，响应通常伴随 WWW-Authenticate 头。注意其名称有误导性——它表示“凭证缺失或无效”，而非“权限不足”；
• 403 Forbidden：服务器理解请求但拒绝执行，与认证状态无关，重新登录也不会改变结果；
• 404 Not Found：资源不存在；已被永久移除的资源更推荐410 Gone；
• 405 Method Not Allowed：资源不支持该HTTP方法，响应应携带 Allow 头说明支持的方法；
• 409 Conflict：请求与资源当前状态冲突，如并发修改或唯一键重复；
• 415 Unsupported Media Type：请求体的媒体类型不被支持；
• 429 Too Many Requests：触发限流，客户端应依据 Retry-After 头退避重试。

七、5xx：服务器错误状态码

• 500 Internal Server Error：服务器内部错误的兜底码，多为未捕获异常。服务端应记录详细日志，而不是把堆栈暴露给调用方；
• 501 Not Implemented：服务器不支持完成请求所需的功能；
• 502 Bad Gateway：网关或代理从上游收到了无效响应，提示问题大概率在服务端链路上游；
• 503 Service Unavailable：服务暂时不可用，常见于过载或维护，可携带 Retry-After 头；
• 504 Gateway Timeout：网关等待上游超时。与502的区别在于：502是“上游答错了”，504是“上游没来得及答”。

八、工程实践建议

1. 按语义选码。若所有响应都返回200、把业务错误塞进响应体，通用中间件（缓存、网关、监控）将无法依据状态码正确工作，可能导致错误响应被缓存、告警漏报等问题。
2. 区分401与403：前者是“你还没证明你是谁”，后者是“我知道你是谁，但你无权执行”。
3. 重试策略区分状态码：429、503按 Retry-After 退避；502、504可指数退避；对POST等非幂等请求重试前要评估重复提交风险，或引入幂等键。
4. 监控按状态码分类统计：5xx突增、401激增（可能是凭证链路异常）、429激增（限流阈值需调整）都是宝贵的运行时信号。
5. 排查分层定位：4xx先检查请求侧（URL、方法、头部、凭证、请求体格式）；5xx沿“客户端→网关→应用→依赖服务→存储”逐层收敛。

一个示意性的请求-响应交互：

POST /api/orders HTTP/1.1
Host: your-api-host
Content-Type: application/json
Authorization: Bearer <token>
{"sku":"A-001","quantity":2}

创建成功时：

HTTP/1.1 201 Created
Location: /api/orders/10086

凭证无效时：

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="orders"

九、结语

HTTP状态码是客户端与服务器之间最精炼的“结果语言”。理解每一个状态码背后的语义约定，不仅能写出更规范的接口，也能在故障发生时快速缩小排查范围。建议开发者以 RFC 7231 与 IANA 注册表为准绳，结合业务场景细化选码策略，让状态码真正发挥“机器可判读、人可理解”的价值。