HTTP状态码详解：从协议规范到工程实践

一、什么是HTTP状态码

HTTP状态码（HTTP Status Code）是服务器对客户端请求所返回的三位数字结果标识，用于表达本次请求在协议层面的处理结果。它最初由HTTP/1.1规范定义，并随着Web能力演进，被多个扩展规范不断补充，同时由互联网号码分配局（IANA）维护官方注册表。

从通信语义上看，状态码是服务器与客户端之间的一种”契约”：客户端依据状态码决定是继续请求、读取响应体、跳转地址、重试还是终止；服务端则通过状态码向调用方表达结果类别，而不必依赖响应体内容。正因如此，状态码不仅是调试工具，更是缓存、重定向、鉴权、限流、幂等重试等机制得以成立的基础。

状态码由三位数字构成，其首位数字决定了它所属的响应类别，共分五类：

• 1xx（信息性）：请求已收到，需继续处理
• 2xx（成功）：请求已被成功接收、理解并接受
• 3xx（重定向）：需要进一步动作才能完成请求
• 4xx（客户端错误）：请求存在语法或语义问题
• 5xx（服务端错误）：服务器在处理请求时失败

需要注意的是，状态码附带的原因短语（如”OK””Not Found”）只是建议性文本，客户端不应依赖它做逻辑判断，真正具有语义的是数字本身。

二、1xx：信息性状态码

1xx表示临时响应，仅包含状态行与可选响应头，并以空行结束，不含响应体。由于HTTP/1.0未定义任何1xx状态码，服务端通常不应向此类客户端发送1xx响应，除非在明确的实验环境下。

100 Continue

客户端在发送大体积请求体前，可先发送带Expect: 100-continue的请求头。服务器若接受，则返回100，客户端继续发送剩余数据；若服务器直接返回最终响应（如4xx），客户端可避免无效传输。这一机制在移动网络或大文件上传场景下能显著节省带宽。

PUT /upload/large-file HTTP/1.1
Host: example.com
Content-Length: 104857600
Expect: 100-continue

101 Switching Protocols

当客户端通过Upgrade头请求切换协议（如升级到WebSocket）时，服务器若同意，返回101，并在Upgrade头中声明新协议。此后连接不再遵循原HTTP语义，而按新协议通信。只有在切换确实带来收益时才应使用，否则会造成连接语义混乱。

102 Processing

该状态码由WebDAV扩展引入，表示服务器已收到并正在处理请求，但尚无最终响应。它主要用于避免客户端在长耗时操作中过早超时。

三、2xx：成功状态码

2xx是最常被期望的结果类别，但”成功”的具体含义因码而异，混用会带来接口语义模糊。

200 OK

最通用的成功响应，响应头或响应体随请求返回。GET、POST、PUT等都可能返回200，但需注意：200并不天然代表”业务成功”，业务层错误若以200返回，会破坏监控与重试逻辑。

201 Created

表示请求已实现，并因此创建了新资源，新资源的URI应通过Location头返回。若资源无法及时创建，应改用202。

HTTP/1.1 201 Created
Location: /users/1024

202 Accepted

服务器已接受请求但尚未处理完成，请求最终可能被执行也可能被拒绝。它适合异步任务提交场景，通常配合任务查询接口使用，客户端不应假设处理一定成功。

204 No Content

请求成功处理，但无需返回实体内容，常见于DELETE或PUT更新操作。客户端不应期待响应体，服务端也不应返回。

206 Partial Content

用于范围请求（Range），表示返回的是资源的一部分，常见于断点续传与视频拖动播放场景，需配合Content-Range头使用。

四、3xx：重定向状态码

3xx的核心是告诉客户端”要完成请求，还需进一步动作”。工程上要特别关注是否改变请求方法以及是否可缓存。

• 301 Moved Permanently：资源永久迁移，客户端与搜索引擎应更新引用，后续请求应使用新URI。
• 302 Found：临时重定向，历史实现中部分客户端会将POST改为GET，需谨慎。
• 303 See Other：明确要求客户端用GET访问新URI，常用于POST后的结果页跳转，避免刷新重复提交。
• 304 Not Modified：配合条件请求使用，表示资源未变更，客户端可复用本地缓存，能显著降低带宽与延迟。
• 307 Temporary Redirect：临时重定向，且明确不改变请求方法，适合需要保持POST语义的场景。
• 308 Permanent Redirect：永久重定向且不改变方法，是307的永久版本。

在设计跳转时，应优先明确”是否永久”和”是否保持方法”两个维度，避免因语义不清导致客户端行为不一致。

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

4xx表示问题出在请求侧，服务端不应通过重试自行修复，客户端需要调整请求。

• 400 Bad Request：请求语法错误或参数不合法，服务端无法或不愿处理。
• 401 Unauthorized：请求需要认证，响应应包含WWW-Authenticate头说明认证方式。语义上它是”未认证”而非”无权限”。
• 403 Forbidden：服务器理解请求但拒绝执行，且通常不应重复认证，与401形成互补。
• 404 Not Found：资源不存在。需注意，部分系统出于安全考虑，会对无权限资源也返回404以避免信息泄露。
• 405 Method Not Allowed：方法不被允许，响应应包含Allow头列出可用方法。
• 408 Request Timeout：服务器等待请求超时，客户端可考虑重发。
• 409 Conflict：请求与资源当前状态冲突，常见于并发更新与唯一性约束。
• 413 Payload Too Large：请求体超出服务器限制，常用于上传接口。
• 429 Too Many Requests：请求频率超限，响应可包含Retry-After指示何时重试，是限流的标准表达。

六、5xx：服务端错误状态码

5xx表示服务端在处理请求时失败，客户端通常可结合幂等性决定是否重试。

• 500 Internal Server Error：通用服务端错误，通常意味着未捕获异常。它是”兜底”状态，不应作为常规业务返回。
• 501 Not Implemented：服务器不支持请求所需功能。
• 502 Bad Gateway：作为网关或代理时，从上游收到无效响应，常见于后端服务崩溃或超时。
• 503 Service Unavailable：服务暂时不可用，可能因过载或维护，响应可包含Retry-After。
• 504 Gateway Timeout：网关等待上游响应超时，与502常被混淆，前者强调”超时”，后者强调”无效响应”。

七、工程实践中的关键要点

1. 状态码与业务码分离

HTTP状态码表达协议层结果，业务结果应放在响应体中。例如参数校验失败应返回400，而非200+业务错误码，否则会破坏缓存、监控与客户端重试判断。

2. 重试策略需区分状态码

只有幂等请求（GET、PUT、DELETE等）在遇到5xx或429时才适合重试，且应配合指数退避与Retry-After。

def should_retry(status, method, attempt):
    if method not in ("GET", "PUT", "DELETE"):
        return False
    if status in (500, 502, 503, 504, 429):
        return attempt < 3
    return False

3. 缓存必须依赖正确的状态码

304、200配合Cache-Control、ETag才能构成有效缓存链路，错误地返回200会导致缓存击穿或脏数据。

4. 监控与告警按类别聚合

将4xx与5xx分开统计：4xx升高通常反映客户端或接口契约变化，5xx升高则直接指向服务端健康度。

5. 避免常见误区

• 不要用200返回所有业务错误；
• 不要用302替代303处理POST后跳转；
• 不要对非幂等请求盲目重试5xx；
• 不要在网关层统一吞掉上游状态码，导致排查困难。

八、总结

HTTP状态码是一套轻量却严谨的语义体系。理解每一位数字背后的协议约定，并在客户端与服务端一致地落实，才能让接口具备可预测、可监控、可重试、可缓存的工程属性。建议团队在接口规范中明确状态码使用清单，将其纳入契约测试与监控体系，从而把”状态码”从调试细节提升为系统可靠性的基础设施。