状态码怎么分类

状态码是三位数字，首位数字定义类别，后两位没有分类含义。1xx 表示信息，2xx 表示成功，3xx 表示需要进一步动作，4xx 表示请求方有问题，5xx 表示服务端有问题。规范要求客户端按类别处理不认识的码，因此自定义状态码必须落在合法类别之内，语义也要与类别一致。这套分类是监控、告警、重试与缓存策略的共同语言：把语义放错类别，等于告诉整条链路一个错误的事实。

基本信息

典型使用场景

• 接口设计：为不同结果选择语义准确的状态码，而不是一律返回成功码
• 网关与代理：按类别决定是否重试、是否缓存、是否改写响应
• 监控告警：按类别区分责任方，减少误报与漏报
• 客户端开发：按类别统一处理，避免逐个数码硬编码
• 排障定位：用类别快速判断是调用方问题还是服务方问题

只看状态码与跳转目标

curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://example.com/   # 打印状态码与跳转目标
curl -sI https://example.com/ | head -3   # 看状态行与关键头部
# 批量检查一组地址的状态码，便于发布后快速巡检
for u in https://example.com/ https://example.com/api/health; do printf '%s ' $u; curl -s -o /dev/null -w '%{http_code}\n' $u; done

五类语义与处理要点

客户端处理原则

• 按首位数字分支，未知码落到类别默认行为，而不是直接判定为失败
• 成功类要区分有无响应体，无内容时不要解析内容
• 进一步动作类要限制跟随次数，避免跳转环导致请求打转
• 请求方错误类要区分可重试与不可重试，避免无意义重试放大日志
• 服务端错误类对非幂等请求不要自动重试，除非有幂等保障

四个常见误用

• 把业务错误塞进成功码，监控看不到真实失败率
• 自定义码落在错误类别，例如用成功类表示客户端中断
• 用请求方错误类表达服务端内部异常，把责任推给了调用方
• 同一语义在不同接口用不同码，调用方无法统一处理

责任方怎么快速判断