这些 HTTP 状态码来自哪里，为什么 418 显示未使用？

英文短语和登记状态按 IANA HTTP Status Code Registry 整理，并保留临时登记、未使用与已废止条目。IANA 当前把 418 登记为 (Unused)；“I'm a teapot”来自历史愚人节协议，适合做彩蛋，不适合作为通用业务错误语义。临时状态码还应在使用前核对注册有效期和草案版本。

参数错误应该返回 400 还是 422？

请求语法、JSON、消息格式或路由参数根本无法解析时通常用 400。媒体类型和语法都能理解，但邮箱、库存、状态转换等业务内容无法处理时通常用 422。团队应把边界写进 API 约定，并让错误体提供字段、原因和稳定错误代码。

401 和 403 有什么区别？

401 表示没有提供有效认证凭据，响应通常还要包含 WWW-Authenticate；403 表示服务器理解请求，但即使身份已知也拒绝执行。不要只根据中文“未授权”猜测，也不要为了隐藏资源存在性而在全站随意混用，是否返回 404 应基于明确的安全策略。

301、302、303、307 和 308 应该怎样选？

301 与 308 表示永久迁移，302 与 307 表示临时跳转；307、308 明确保留原请求方法和请求体。303 则明确引导客户端用 GET（HEAD 仍为 HEAD）访问另一个地址，适合 POST 后查看结果。搜索迁移还要同步内链、canonical、Sitemap，并实际检查第一跳状态。

遇到 429、502、503、504 可以立即重试吗？

不要无条件立即并发重试。429 和 503 应优先遵守 Retry-After；502、504 的幂等请求可以使用指数退避、抖动和次数上限。POST 等非幂等操作要先确认服务端是否已经执行，并通过幂等键或状态查询避免重复扣款、创建或发送。

选对状态码以后，错误响应就设计完整了吗？

没有。状态码只能表达一层通用语义，生产 API 还需要稳定的错误结构、可读说明、字段错误、业务错误代码、请求 ID 与日志关联信息。不要在 200 响应体里再藏“实际失败”，也不要向用户暴露堆栈、SQL 或内部密钥。

← 返回工具箱

开发 / HTTP SEMANTICS

HTTP 状态码查询与选码助手

收录 IANA 当前登记的 64 个具体状态码，区分正式、临时、未使用和已废止条目。可按代码、英文、中文或排查关键词搜索，并用常见 API 场景对比容易混淆的状态码。

状态码、英文短语、中文含义或关键词

只看常用状态码

匹配 64 项

API DECISION HELPER

这个场景该用哪个状态码？

选择最接近的情况

JSON 格式正确，但邮箱、库存或业务规则不通过。

通常用 422；如果连请求语法、JSON 或路由参数都无法解析，用 400。

数据口径

注册状态与英文短语来自 IANA HTTP Status Code Registry（本地数据更新到 2025-09-15）。中文说明与排查建议是便于开发使用的解释，不代替对应 RFC 的完整规范语义。

状态码本身不能说明所有重试、缓存和错误详情。生产 API 还应提供稳定的错误结构、请求 ID、日志关联信息，并防止客户端对非幂等请求盲目重试。

RELATED TOOLS

查看全部工具 →

HTTP Header 解析粘贴真实响应头，检查状态行、缓存和安全字段。Cache-Control生成并诊断浏览器与 CDN 缓存策略。CORS 诊断判断预检请求并校验跨域响应策略。重定向规则批量生成 301、302、307 与 308 配置。