简介：本文系统梳理 HTTP 状态码的分类体系与常见码位含义，结合 API 设计、客户端处理和服务端排障等实际场景，说明如何正确选择与使用状态码，帮助开发者构建语义清晰、易于维护的接口。
HTTP 状态码是服务端在处理完一次请求后，返回给客户端的标准语义标记。它由三位数字构成，承载的是“请求结果如何”这一关键信息。对于客户端开发者来说，状态码决定了后续应当执行的成功处理、失败重试、错误提示还是权限跳转；对于服务端开发者来说，状态码是实现自描述接口、减少沟通成本的重要工具。
一个设计良好的 HTTP 接口，不应该只依赖响应体中的业务字段来表达结果。即使响应体中写明了错误原因，状态码仍然承担着第一层语义传递的任务。很多网络中间件、网关、监控系统和浏览器缓存机制都会优先识别状态码来做出决策。因此，准确理解并合理使用状态码，是后端开发、接口设计以及前端联调中的基础能力。
HTTP 状态码按照首位数字划分为五个大类，分别对应不同层级的处理结果。
理解这一分类非常重要，因为它能帮助开发者快速判断问题归属。联调时常见的“到底是谁的锅”之争，很多时候通过状态码的首位数字就能直接得出结论。
这是最常见、也是使用范围最广的状态码，表示请求已经成功，并且服务端正常返回了内容。它适用于 GET 查询、POST 更新、DELETE 删除等多种语义场景。例如客户端请求某个资源详情时，服务端校验通过并返回资源数据，通常使用 200。
需要注意的是，200 不代表“没有发生任何变化”，它只表示请求被正确处理。如果一个更新接口即使没有修改任何字段也返回 200，在语义上是可接受的，但如果希望进一步区分“已修改”和“未修改”，则可以考虑使用 204 或配合响应体中的业务字段综合表达。
用于表示请求成功且服务端创建了一个新的资源。它在 RESTful 接口设计中尤其重要。比如用户提交注册信息、创建一个新订单、上传一个新文件等场景，都适合返回 201。
返回 201 时，通常建议在响应头中通过 Location 字段给出新资源的访问地址。这样客户端无需额外构造链接，可以直接根据 Location 跳转或保存资源标识。这一做法能让接口的语义更加完整，也便于后续的资源管理。
表示请求成功，但响应体中没有内容可以返回。它常用于删除操作、无返回值的更新操作或者一个仅仅需要确认成功的请求。例如批量删除任务成功、消息已标记为已读等场景，使用 204 可以避免返回无意义的空对象。
使用 204 时，响应体必须为空。这种设计能让客户端明确知道“不需要解析响应体”，从而简化前端处理逻辑。
表示请求的资源已经被永久移动到了新的地址，客户端以后应使用新的 URL 进行访问。浏览器在遇到 301 时会自动跳转，并且搜索引擎也会据此更新索引。
301 适用于域名更换、URL 结构调整、HTTP 升级到 HTTPS 等长期有效的地址变更场景。由于浏览器会缓存 301 结果，因此如果重定向策略只是暂时的，不应使用 301。
302 表示资源临时移动到另一个位置。与 301 相比，它不会让客户端长期记住新地址，每次请求仍会先访问原地址。
303 则更进一步约束语义：服务端要求客户端使用 GET 方法请求新的地址，即使原始请求是 POST。它常用于表单提交后的跳转场景，避免用户刷新页面时重复提交数据。
304 属于缓存相关状态码。当客户端携带条件请求头，例如 If-Modified-Since 或 If-None-Match，服务端判断资源没有变化时，返回 304 告知客户端可继续使用本地缓存。
304 本身不包含响应体，它的意义在于减少带宽消耗和提升响应速度。对于静态资源、接口返回内容变化不频繁的场景，合理使用 304 能显著降低服务端压力。
表示请求本身存在语法问题或参数错误，但错误不属于更具体的状态码范畴。例如缺少必填参数、参数格式不正确、JSON 解析失败等。
400 容易被过度使用。更好的实践是：当错误可以被更具体的状态码描述时，应优先使用更精确的码位。例如身份校验失败用 401，权限不足用 403，资源不存在用 404，参数格式问题才使用 400。
表示当前请求缺少有效的身份凭证。客户端需要提供正确的认证信息，例如登录令牌、签名或证书，才能继续访问。它的语义重点在于“未认证”而不是“无权限”。
实际开发中，401 通常与响应头中的 WWW-Authenticate 字段配合使用，提示客户端采用何种认证方式。例如 API 令牌过期、请求未携带认证信息等情况，都适合返回 401。
表示客户端身份已经被识别，但该身份没有权限访问目标资源。与 401 不同，403 的重点是“已认证但被拒绝”。
举一个典型场景：普通用户尝试访问管理员接口。服务端能够确认该用户的身份，但根据权限策略不允许其执行该操作，此时应返回 403。使用 403 能避免将权限错误与认证错误混为一谈，便于前端做出不同的交互引导。
表示服务端找不到请求对应的资源。它既可以指资源确实不存在，也可以用于隐藏某些敏感资源的真实存在性。例如用户查询某个订单编号，数据库中没有对应记录，返回 404 是常见做法。
在接口设计中，404 有时会与业务层面的“无数据”混淆。如果请求的路径本身正确，但查询结果为空，既可以使用 200 配合空列表表达，也可以根据接口约定使用 404。关键在于团队内部保持统一口径，避免前后端理解偏差。
表示请求方法不被目标资源支持。例如一个只读接口收到了 POST 请求，或者某个资源只允许 GET 和 DELETE，但客户端使用了 PUT。
返回 405 时，建议在响应头中携带 Allow 字段，明确列出该资源支持的方法。这样能够帮助客户端快速修正请求方式，也利于后续自动生成接口调用代码。
表示请求格式正确，但语义层面无法处理。它常用于表单校验失败、业务规则冲突等情况。例如字段值不符合业务约束、密码强度不满足要求等。
相比 400，422 更好地表达了“请求能解析通过，但业务上不成立”的含义。在前后端分离架构中，使用 422 可以让前端更准确地区分格式错误和业务校验失败两类问题。
这是最笼统的服务端错误状态码，表示服务端在处理请求时发生了未预期的异常。它不代表具体原因，而是一个通用兜底。
500 不应被频繁使用。如果服务端日志中频繁出现 500，往往说明存在薄弱环节需要重点排查。对于客户端来说，收到 500 一般意味着可以稍后重试，因为问题可能出在服务端临时状况上。
表示服务端作为网关或代理时，从上游服务收到了无效响应。它常见于多层服务架构中，例如网关转发请求到后端服务，但后端没有返回合法内容。
502 的出现经常指向上游服务崩溃、超时或内部通信故障。排查时通常需要结合网关日志和上游服务日志一起定位。
表示服务暂时不可用，可能因为过载、维护、限流或临时故障。与 500 相比，503 更强调“临时性”和“可恢复性”。
返回 503 时，建议在响应头中提供 Retry-After 字段，告知客户端建议的重试时间。这样客户端可以实现更智能的退避重试机制，而不是盲目高频重试，加剧服务端压力。
表示网关或代理在等待上游服务响应时超时。与 502 的区别在于：504 明确表达了“等待超时”这一原因。
当客户端请求触发了一个耗时的上游调用，比如复杂报表查询或第三方依赖调用的时间超出阈值时，网关可能返回 504。缓解 504 通常需要从上游服务性能优化、超时阈值调整或异步任务化改造等方面入手。
同一个业务含义，不应在不同接口中使用不同的状态码。例如登录失败统一返回 401，权限不足统一返回 403。语义一致性可以降低前端封装请求工具时的复杂度，也有助于自动生成文档和测试用例。
状态码负责表达传输层面的结果，业务码负责表达领域逻辑中的细分结果。两者不应互相替代。比如所有业务失败都返回 200，然后在响应体中写一个“错误码”，这种做法会让网关、监控系统和浏览器无法感知错误发生，不利于系统整体可观测性。
更合理的做法是：用 4xx 或 5xx 表达整体错误类别，同时在响应体中提供更具体的业务错误描述和解决方案提示。
返回 5xx 时，响应体不要包含堆栈信息、数据库结构、内部路径等敏感内容。这些信息可以被记录在服务端日志中，但不应直接返回给客户端，否则可能带来安全隐患。
不同的状态码对缓存和重试策略有不同的影响。2xx 中的 200 通常允许缓存，而 204 多用于不需要缓存的场景；4xx 一般不应被自动重试，因为错误来自请求本身；5xx 中的 502 或 503 则适合客户端进行有限次数的退避重试。
理解状态码对中间件行为的影响，有助于设计更健壮的分布式系统。
HTTP 状态码虽然只有三位数字，但它是客户端与服务端之间最基础、最高频的协议语言。掌握它的分类逻辑、理解常见码位的细微语义差异，能够在接口设计、异常定位和用户体验优化中发挥实际作用。
从 200 的通用成功，到 201 的资源创建，从 304 的缓存协商，到 401 与 403 的认证权限区分，再到 502、503、504 对服务端异常的非精确但方向性表达，每一个状态码都承担着明确的任务。合理使用它们，不仅能让接口更规范，也能让团队协作更高效、排障路径更清晰。