HTTP状态码详解：分类、语义与工程实践

一、HTTP状态码是什么

当客户端（浏览器、移动应用或另一个后端服务）向服务器发起HTTP请求后，服务器返回的响应报文第一行就是“状态行”，其中包含协议版本、一个三位数字的状态码，以及一段人类可读的短语，例如：

HTTP/1.1 200 OK

这个三位数字就是HTTP状态码（HTTP Status Code），用以表示服务器对请求的处理结果。关于它，有几个关键事实值得了解：

• 规范来源：状态码最早由RFC 2616规范定义，随后由RFC 2518、RFC 2817、RFC 2295、RFC 2774、RFC 4918等文档不断扩展；HTTP/1.1时代的状态码定义主要集中在RFC 7231等文档中。
• 官方注册表：所有合法状态码由国际互联网编号分配机构统一注册维护，保证全球范围内语义一致、互不冲突。
• 数字即语义：状态码的第一位数字代表响应的五大类别之一，后两位用于在类别内进一步细分。
• 短语仅供参考：状态行中的消息短语（如”OK””Not Found”）只是典型的可读描述，服务端可以替换为任何自定义文案，客户端程序应以数字为准。
• 子代码只是补充：个别服务器软件会在响应正文或日志文档中附加形如”x.y”的十进制子代码，用于更精细地定位错误原因，但它只出现在有效内容和文档中，并不替代标准的三位状态码。

二、五大类别总览

首位数字	类别	一句话语义
1xx	信息性响应	请求已收到，处理还在继续
2xx	成功	请求已被接收、理解并接受
3xx	重定向	需要客户端进一步操作才能完成请求
4xx	客户端错误	请求本身有问题，服务器无法处理
5xx	服务器错误	请求合法，但服务器处理时出了问题

下面按类别逐一展开。

三、1xx 信息性响应：“先别挂断，还有下文”

这类状态码是临时响应，报文只包含状态行和部分响应头，以一个空行结束，不携带实体内容。由于HTTP/1.0协议没有定义任何1xx状态码，除非处于试验条件，服务器不应向HTTP/1.0客户端发送这类响应。

100 Continue：通知客户端“目前的请求部分已被接收，且尚未被拒绝，请继续发送剩余内容”。它通常与请求头Expect: 100-continue配合使用：当客户端要上传大体积请求体时，先发送头部探询服务器意愿，收到100后再传输数据，避免“传完大文件却被拒绝”的浪费。如果请求已发送完毕，客户端可以忽略该响应；服务器在请求处理完成后，仍必须发送一个最终响应。

101 Switching Protocols：服务器已理解客户端请求，并将通过Upgrade消息头通知客户端采用不同协议来完成本次通信。发送完本响应最后的空行后，服务器即切换到Upgrade头中定义的协议。典型例子是从HTTP升级到支持实时、双向通信的长连接协议。需要注意的是，只有在新协议能带来明确收益时才应切换，例如升级到更具优势的HTTP新版本，或切换到适合实时同步传输的协议。

102 Processing：由WebDAV扩展（RFC 2518）引入，表示服务器已收到请求、处理仍将继续执行，用于防止客户端因长时间收不到任何响应而误判超时、主动断开连接。

四、2xx 成功响应：“事情办成了”

200 OK：最常见的成功状态码，表示请求已成功，所期望的响应头或数据体将随响应返回。GET请求通常返回资源内容，POST请求返回处理结果。出现此状态码即代表正常状态。

201 Created：请求已实现，并且依据请求创建了新资源，新资源的URI通过Location响应头返回。这是RESTful风格中POST创建资源后的标准返回。如果资源无法及时创建（例如需要异步生成），则应返回202。

202 Accepted：服务器已接受请求，但尚未处理完成。请求最终可能被执行，也可能被拒绝。它适合异步任务场景——服务器先把请求放进队列，稍后处理。良好的实践是在响应体中附带任务查询入口，让客户端可以轮询进度。

204 No Content：服务器成功处理了请求，但不需要返回任何实体内容。常用于DELETE成功后的响应、纯状态更新等场景。注意204响应在协议层面不允许携带消息体，这与“200 + 空body”是有区别的。

206 Partial Content：客户端使用了Range请求头，服务器只返回资源的部分内容。它是断点续传、大文件分片下载、音视频拖动播放等技术的基础。

五、3xx 重定向：“资源换地方了，或没有变化”

301 Moved Permanently：永久重定向，资源已永久迁移到新URI。搜索引擎会据此把旧地址的索引权重转移到新地址，因此网站更换域名、调整URL结构时应优先使用301。

302 Found：临时重定向，资源暂时位于其他URI。搜索引擎通常不转移权重，适合短期活动页、临时跳转等场景。

303 / 307 / 308：用于补齐语义空白。303要求客户端改用GET方法访问新URI，常用于POST表单提交后跳转到结果页，避免刷新导致重复提交；307和308分别是302和301的“严格版”，要求重定向时不得改变原有请求方法，对接口迁移尤其重要。

304 Not Modified：缓存协商的核心。客户端携带If-None-Match（对应ETag）或If-Modified-Since（对应Last-Modified）发起条件请求，服务器判断资源未变化时返回304，省去传输完整响应体的开销。这是Web性能优化中性价比极高的手段。

实践提醒：301与302、307与308的选择要慎重，它们直接影响搜索引擎收录与请求幂等性；同时要警惕重定向链条过长或形成循环。

六、4xx 客户端错误：“问题出在请求上”

• 400 Bad Request：请求语法错误或参数格式非法，服务器无法理解。
• 401 Unauthorized：未认证。请求缺少有效身份凭证，响应通常携带WWW-Authenticate头说明认证方式。注意其语义是“未认证”而非“未授权”。
• 403 Forbidden：服务器已理解请求，但拒绝执行。与401不同，客户端身份可能已被识别，只是没有权限，此时重试毫无意义。
• 404 Not Found：服务器找不到请求的资源。它是最著名的状态码，也最常被滥用——不要把所有错误都笼统地包装成404。
• 405 Method Not Allowed：请求方法不被允许，例如对只读资源发起DELETE。
• 409 Conflict：请求与资源当前状态冲突，典型如并发更新时的版本冲突。
• 410 Gone：资源已永久消失。与404相比，它明确告诉客户端“别再来了”，也有助于搜索引擎更快清理失效索引。
• 413 / 415 / 422：分别表示请求体过大、不支持的媒体类型、请求语义无法处理（常见于参数校验失败）。
• 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是“上游迟迟不答复”。

从排障角度看，三者指向不同方向：500多与业务代码有关，502/504多与部署链路和上游健康度有关，503则常与容量、限流或运维动作有关。

八、工程实践：把状态码用对、用好

1. 拒绝“一律200”的反模式。不少接口把所有响应都返回200，再用响应体中的自定义字段表达成败。这会让浏览器缓存、网关策略、监控系统、重试机制全部失效——它们都依赖标准状态码判断结果。正确姿势是：状态码表达HTTP层面的结果，业务细节放在响应体中。

2. RESTful场景的状态码映射（示意）：

GET    /api/orders/123   → 200（成功）/ 404（不存在）
POST   /api/orders       → 201 + Location（创建成功）/ 400（参数非法）/ 422（业务校验失败）
PUT    /api/orders/123   → 200 或 204（更新成功）/ 409（版本冲突）
DELETE /api/orders/123   → 204（删除成功）
未携带有效凭证 → 401；权限不足 → 403；触发限流 → 429 + Retry-After

3. 统一错误响应结构。返回4xx/5xx时，建议在响应体中提供稳定、机器可读的错误描述：

HTTP/1.1 400 Bad Request
Content-Type: application/json
{"error": "invalid_parameter", "message": "字段 quantity 必须为正整数"}

4. 用状态码驱动监控与告警。按状态码维度统计流量分布，是发现故障最直接的手段：5xx比例突增往往意味着服务端异常，4xx激增可能预示攻击、爬虫或客户端版本缺陷。建议将“5xx比例”“429次数”“502/504次数”纳入核心监控面板，并结合日志服务与监控告警类能力配置告警规则。

5. 善用缓存相关状态码。合理组合Cache-Control、ETag与304、206，可显著降低带宽成本、提升访问速度，尤其适合静态资源与大文件分发场景。

6. 高效调试。浏览器开发者工具的Network面板可以直观查看每个请求的状态码与响应头；命令行HTTP客户端则适合查看原始报文、验证重定向与缓存协商行为。

九、小结

HTTP状态码是一套紧凑而表达力强的“通信结果语言”：三位数字，划分五大类别，覆盖了从“继续发送”到“网关超时”的完整链路反馈。理解每个状态码的准确语义，在接口设计、缓存策略、限流保护与故障排查中恰当地使用它们，是每一位开发者都应具备的基本功。状态码用得规范，系统间的协作才会更顺畅，问题定位也会更快、更准。