简介：系统梳理HTTP状态码的分类、语义、典型场景与排查方法，帮助开发者准确理解1xx到5xx状态码在请求处理、重定向、客户端错误与服务端错误中的实际含义，并结合常见Web服务与API设计场景，给出可落地的状态码选择与诊断建议。
HTTP状态码是Web通信中最基础也最容易被误读的一部分。无论是前端开发者调试接口、后端工程师设计API，还是运维人员排查线上故障，都离不开对状态码语义的准确理解。本文将从协议规范出发，结合真实业务场景，系统梳理HTTP状态码的分类、含义、使用策略与诊断方法，帮助读者建立完整的状态码知识框架。
HTTP状态码由三位十进制数字组成，是服务器对客户端请求处理结果的简洁表达。它由RFC 2616规范定义，并经过RFC 2518、RFC 2817、RFC 2295、RFC 2774、RFC 4918等规范扩展，目前在HTTP/1.1标准（RFC 7231）中形成统一约定，由互联网号码分配局（Internet Assigned Numbers Authority）负责维护官方注册表。
状态码的第一位数字将响应划分为五个大类，这一设计使客户端无需解析完整响应体即可快速判断处理策略：
需要注意的是，状态码后面跟随的“原因短语”（如OK、Not Found）只是建议性描述，服务器可以提供更易读的替代文本。但状态码本身是规范化的，客户端必须按照状态码的类别语义进行处理，而不能依赖原因短语做逻辑判断。
1xx类是HTTP协议中最少被开发者实际接触的一类状态码。这类响应属于临时响应，仅包含状态行和可选的响应头信息，以一个空行结束，不携带响应体。它们的作用是在最终响应到来之前，向客户端传递中间处理信息。
在HTTP/1.0协议中没有定义任何1xx状态码，因此服务器通常需要避免向仅支持HTTP/1.0的客户端发送这类响应。即使在HTTP/1.1及以上版本中，1xx响应的使用也需要谨慎，因为部分代理和客户端实现对其支持并不完整。
100 Continue是最常用的1xx状态码。它的典型工作场景是：客户端准备发送一个大体积请求体（例如文件上传），先发送包含Expect: 100-continue请求头的初始请求，服务器如果愿意接收请求体，则返回100 Continue，客户端再继续发送剩余数据。
这一机制的价值在于避免客户端在服务器已经拒绝请求（例如认证失败或请求体过大）的情况下，仍然浪费带宽上传大量数据。服务器在返回100 Continue后，必须在请求处理完成时发送一个最终响应。
101 Switching Protocols表示服务器理解并接受客户端通过Upgrade请求头提出的协议切换请求。服务器在发送该响应后，将切换到Upgrade头中指定的协议进行后续通信。
典型的应用场景是从HTTP/1.1升级到WebSocket协议。切换协议只有在新的协议能带来明显优势时才值得进行，例如更高的实时性、更低的延迟或双向通信能力。
102 Processing由WebDAV（RFC 2518）扩展定义，用于告知客户端服务器已收到请求并正在处理，但尚未完成。这个状态码主要出现在处理时间较长的WebDAV操作中，用来防止客户端超时。在普通的HTTP API中极少使用。
2xx是开发者日常工作中遇到最多的一类状态码，它表明请求已经成功被服务器接收、理解并接受。但不同2xx状态码之间存在语义差异，准确选择有助于客户端更好地处理响应。
200 OK是最常见的成功状态码，表示请求已成功处理，所期望的响应数据（响应头或响应体）将随此响应返回。它适用于GET、POST、PUT、DELETE等多种方法，是一个通用性的成功表示。
但正因为其通用性，200 OK在API设计中被过度使用。例如，将业务层面的失败也用200 OK返回，然后在响应体中通过自定义字段（如{"code": 500}）表达错误，这种做法弱化了HTTP语义，使缓存、重试、监控等基础设施层能力难以发挥作用。
201 Created表示请求已被成功执行，并且服务器创建了一个新的资源。新资源的URI通过Location响应头返回给客户端。该状态码最常用于POST请求创建资源的场景，例如创建用户、上传文件、新建订单等。
如果请求的资源无法被立即创建（例如需要异步处理），则应返回202 Accepted，而不是201 Created。这一区别对于客户端判断资源是否立即可用非常关键。
202 Accepted表示服务器已接受请求，但尚未完成处理。请求最终可能被执行，也可能被拒绝。这个状态码适用于异步处理的场景，例如提交一个批量任务、触发一个需要长时间运行的数据处理流程。
返回202 Accepted时，服务器通常应在响应体中提供一个任务ID或状态查询接口的URI，使客户端可以后续查询处理进度。如果响应中没有任何关于处理状态的信息，客户端将无从判断请求的最终结果。
虽然原文没有展开说明，但作为2xx家族的重要成员，204 No Content表示请求已成功处理，但响应体中不包含任何内容。它常用于DELETE操作成功后的响应，以及不需要返回任何数据的PUT或POST操作。
使用方法是否得当，直接影响着API设计的语义准确性。例如，DELETE删除资源成功后返回200 OK并附带一个空JSON对象，虽然不影响功能，但语义上使用204 No Content更为规范和清晰。
3xx状态码表示客户端需要采取进一步的操作才能完成请求。在Web应用中，重定向处理得不好会导致循环跳转、SEO问题或安全漏洞。
301表示请求的资源已被永久移动到一个新的URI，响应中的Location头给出了新的地址。搜索引擎和浏览器会更新书签和索引，后续请求会直接访问新的URI。
302表示资源临时从另一个URI访问。与301不同，302意味着资源的移动是临时的，客户端后续仍应使用原始URI。然而，在实际实现中，302的重定向语义在POST请求下可能存在不一致，因此HTTP/1.1引入了更明确的303和307来区分不同场景。
304是一个特殊的状态码，它与缓存机制紧密配合。当客户端发送带有If-None-Match或If-Modified-Since头的条件请求时，如果资源未被修改，服务器返回304，表示客户端可以使用本地缓存的版本，响应体为空。
正确使用304可以显著减少带宽消耗和响应延迟。结合ETag和Last-Modified等缓存验证机制，304在Web性能优化中扮演着重要角色。
4xx状态码表示请求存在错误，而这个错误源于客户端。服务器应当返回一个包含错误描述的响应体，帮助开发者或用户理解问题所在。
400表示服务器无法理解请求的语法。常见原因包括JSON格式错误、参数缺失或类型不匹配、URL编码错误等。API设计中，400通常用于参数校验失败。
401表示请求需要用户身份认证。语义上更准确的表述是“未认证”：用户尚未提供任何有效的身份凭据。响应中应包含WWW-Authenticate头，指示客户端如何提供凭据。
开发者常将401与403混淆。两者的区别在于：401是“你是谁我不知道”，403是“我知道你是谁，但你不能干这件事”。
403表示服务器已经理解请求，但拒绝执行。与401不同，该状态下用户身份可能已经确认，但缺乏访问该资源的权限。例如普通用户尝试访问管理员接口。
404表示服务器找不到请求的资源。它是最为人熟知的状态码之一。在API设计中，404也可用于隐藏资源的存在性，例如在出于安全考虑不希望暴露某个资源是否存在时，统一返回404。
405表示请求方法不被目标资源支持。例如对一个只读资源发送POST请求。服务器应在响应中包含Allow头，列出该资源支持的方法。
429用于限流场景，表示客户端在一定时间内发送了过多请求。响应中通常包含Retry-After头提示客户端多久后可以重试。
5xx状态码表示服务器在处理有效请求时发生了错误。这类错误通常需要运维或后端开发人员介入排查。
500是最通用的服务端错误状态码，表示服务器遇到意外情况，无法完成请求。它通常由未捕获的异常、配置错误或依赖服务故障引起。
502表示服务器作为网关或代理时，从上游服务器收到无效响应。在反向代理架构中常见，例如代理层能够正常工作，但后端服务崩溃或返回了不符合协议的响应。
503表示服务器暂时无法处理请求，通常是因为过载或维护。响应中应包含Retry-After头，告知客户端何时可以重试。
504表示网关或代理服务器在等待上游服务器响应时超时。它通常指向后端服务性能问题或网络连通性问题。
在实际项目开发中，建议遵循以下原则来选择状态码：
对于基础设施层来说，云服务中通常会结合负载均衡、API网关、监控告警等通用能力，在状态码出现异常（如5xx比例升高或特定错误码突增）时自动触发告警，帮助团队快速响应。日志服务的请求追踪能力也可以将状态码与具体请求链路关联起来，加速问题诊断。
状态码虽然只是三位数字，但它们构成了HTTP协议语义的核心。准确理解和使用状态码，不仅能提升API的设计质量，也能让整个系统的可观测性和可维护性更上一个台阶。