HTTP状态码全解：从协议语义到工程实践

一、状态码的本质：协议层的结构化契约

HTTP状态码是服务器对请求处理结果的三位数字编码，位于响应报文的状态行中，形如 HTTP/1.1 200 OK。它并非简单的”成功/失败”标记，而是客户端与服务端之间一份结构化的契约：客户端依据首位数字即可判断响应的宏观类别，再结合具体码值决定后续行为——是否重试、是否读取响应体、是否复用连接、是否更新缓存。

这套机制由早期HTTP规范确立，并随协议演进不断扩充。现行HTTP/1.1语义规范（RFC 7231）是绝大多数状态码的权威来源，WebDAV（RFC 4918）等扩展规范则补充了与资源操作相关的大量码位。所有状态码的官方注册表由互联网号码分配局（IANA）统一维护，任何新增码位都需经过注册流程，以保证全球范围内语义一致。需要强调的是，状态码的三位数字中，首位数字定义了响应的类别，后两位仅用于在该类别内区分具体语义；消息短语（Reason Phrase）只是便于人类阅读的提示，客户端不应依赖其内容做逻辑判断。

部分服务器实现会在响应体或文档中使用额外的十进制子代码来携带更细粒度的诊断信息，但这些子代码不能替代标准状态码本身——标准码位始终是协议层唯一可被互操作识别的信号。

二、五类状态码的语义边界

2.1 1xx：信息性响应，请求仍在处理中

1xx 属于临时响应，仅包含状态行与可选的响应头，以空行结束，不携带响应体。其作用是向客户端同步”请求已被接收，处理仍在继续”的中间状态。由于 HTTP/1.0 未定义任何 1xx 码位，对使用该版本协议的客户端，服务器不得主动发送 1xx 响应（实验性场景除外）。

• 100 Continue：客户端发送 Expect: 100-continue 请求头后，服务器以此响应告知”已收到请求头且未拒绝，可以继续发送请求体”。这在传输大体积请求体时尤为有用——客户端可先探测服务器是否愿意接受，避免浪费带宽上传后被拒。服务器在请求体接收完毕后，必须再发送一个最终响应。
• 101 Switching Protocols：服务器接受客户端通过 Upgrade 头发起的协议切换请求，并在响应结束后切换到新协议。典型场景包括升级到更高版本的HTTP，或切换到支持双向实时通信的协议以传输此类特性所需的资源。是否切换应基于”新协议明显更优”的判断，而非无条件接受。
• 102 Processing：由WebDAV扩展引入，表示服务器已收到并正在处理请求，但尚无最终结果，用于避免客户端在长耗时操作中过早超时。

2.2 2xx：成功，请求已被接收、理解并接受

2xx 表示请求在语义上被正确处理，但不同码位对”成功”的界定各有侧重。

• 200 OK：最通用的成功响应，响应头或响应体随请求的期望返回。这是正常业务流程的默认选择。
• 201 Created：请求导致新资源被创建，且新资源的URI通过 Location 响应头返回。若资源无法即时创建，应改用 202 而非勉强返回 201。
• 202 Accepted：请求已被接受但尚未处理完成，通常用于异步任务——服务器已受理，处理结果需通过其他机制（如轮询、回调）获取。该响应不作任何处理结果的承诺。
• 204 No Content：请求成功但无响应体返回，常用于不需要返回数据的写操作（如删除、更新）。客户端应保持当前页面状态不变。
• 206 Partial Content：响应仅包含资源的一部分，配合 Range 请求头实现断点续传与分块下载。响应中必须携带 Content-Range 头说明片段范围。

2.3 3xx：重定向，客户端需采取进一步动作

3xx 的核心语义是”请求的目标不在当前位置，客户端需按指示再发起请求”。区分各类重定向的关键在于两点：是否改变请求方法，以及是否可缓存。

• 301 Moved Permanently：资源已永久迁移至新URI，后续请求应直接使用新地址。多数客户端会将 POST 改为 GET，且该响应默认可被缓存，适用于域名迁移、URL规范化等场景。
• 302 Found：临时重定向，资源暂时位于别处。历史上客户端对 POST 的处理不一致，实践中多被改为 GET，因此不适合需要保持方法的场景。
• 303 See Other：明确要求客户端以 GET 方法访问 Location 指定的URI，常用于”POST后重定向”模式，避免刷新导致重复提交。
• 304 Not Modified：配合条件请求使用——客户端携带 If-None-Match 或 If-Modified-Since，服务器判断资源未变化时返回 304，响应无 body，客户端直接复用本地缓存。这是缓存机制中节省带宽的关键码位。
• 307 Temporary Redirect 与 308 Permanent Redirect：分别对应 302 与 301 的语义，但严格保持原请求方法与请求体，适合非 GET 请求的重定向场景。

2.4 4xx：客户端错误，请求本身存在问题

4xx 表明错误归因于请求方——语法错误、认证缺失、资源不存在或权限不足。服务器返回 4xx 时，通常意味着客户端在不修改请求的前提下重试无意义。

• 400 Bad Request：请求语法错误或参数无法解析，服务器拒绝处理。应在响应体中给出可读的错误说明，便于定位。
• 401 Unauthorized：请求缺少有效认证凭据。响应必须携带 WWW-Authenticate 头说明认证方式，客户端据此发起认证流程。注意其语义实为”未认证”而非”未授权”。
• 403 Forbidden：服务器理解请求但拒绝执行，且通常不愿说明原因。与 401 的区别在于：403 场景下身份已知但权限不足，重新认证无济于事。
• 404 Not Found：目标资源不存在。需注意区分”资源确实不存在”与”出于安全考虑隐藏资源存在性”两种用法。
• 405 Method Not Allowed：请求方法不被目标资源支持，响应应携带 Allow 头列出可用方法。
• 409 Conflict：请求与资源当前状态冲突，常见于并发更新场景，客户端需先获取最新状态再重试。
• 429 Too Many Requests：客户端在给定时间内发送请求过多，响应宜携带 Retry-After 头指示重试等待时间，是限流策略的标准表达方式。

2.5 5xx：服务端错误，请求本身可能并无问题

5xx 表示服务器在处理看似有效的请求时失败。客户端通常可对幂等请求进行有限重试，但需配合退避策略。

• 500 Internal Server Error：服务器遇到未预期的内部错误，无法完成请求。这是兜底码位，不应滥用——能归因到具体原因的应优先使用更精确的码位。
• 502 Bad Gateway：作为网关或代理的服务器从上游收到无效响应，常见于反向代理后面的服务异常。
• 503 Service Unavailable：服务器暂时无法处理请求，多因过载或维护。响应宜携带 Retry-After，并明确这是临时状态。
• 504 Gateway Timeout：网关等待上游响应超时。与 502 的区别在于：502 是上游返回了无效响应，504 是上游根本没有及时响应。

三、工程实践中的状态码设计原则

3.1 语义优先，避免”万物皆 200”

接口设计中一个常见反模式是：无论成功失败一律返回 200，把错误信息塞进响应体。这会让HTTP层面的可观测性完全失效——监控系统无法通过状态码统计错误率，网关与负载均衡无法基于状态码做熔断，缓存层也无法正确判断响应语义。正确做法是让状态码承载协议层语义，响应体承载业务层细节。

3.2 精确优先于兜底

能使用 400 系列具体码位时，不要退回 500；能区分 401 与 403 时，不要混用。精确的码位直接降低了排障成本：运维看到 429 就知道是限流，看到 504 就知道要查上游超时，无需逐条翻日志。

3.3 状态码与缓存策略联动

Cache-Control、ETag、Last-Modified 等头部的效果高度依赖状态码。例如 304 的生效前提是条件请求头与资源校验值匹配；301 与 308 默认可缓存，而 302 与 307 默认不缓存。设计重定向时若忽略这一差异，可能造成客户端长期沿用过期跳转。

3.4 错误响应应具备可操作性

统一的错误响应结构能显著提升客户端处理效率。示例如下：

{
  "code": "RESOURCE_NOT_FOUND",
  "message": "请求的资源不存在",
  "requestId": "req-7f3a9c21",
  "retryable": false
}

其中 requestId 用于跨服务链路追踪，retryable 显式告知客户端是否值得重试，与 5xx 的重试策略形成配合。

3.5 重试策略需区分码位

并非所有失败都适合重试：429 与 503 通常可重试（配合 Retry-After），500 可有限重试，而 400、401、403、404、409 在请求未修改前重试无意义。对非幂等方法（如 POST），重试还需引入幂等键机制，防止重复创建。

四、结语

状态码是HTTP协议中最容易被低估的设计。它既是机器可读的控制信号，也是人可读的诊断入口。理解每个码位背后的语义边界、缓存行为与方法约束，才能在接口设计、网关配置、监控告警与客户端容错中做出一致且正确的决策。把状态码用对，本质上是在为整个系统的可观测性与可维护性打地基。