HTTP 状态码是服务端对「这次请求结果」的标准化摘要。写前端、做网关、做安全测试时，都要能从状态码判断：问题在客户端、权限、资源，还是服务端。下面按类别把最常见的码讲清楚。
1xx 信息性（少见）
表示临时响应，如 100 Continue。日常业务代码很少直接处理。
2xx 成功
| 码 | 含义 | 备注 |
|---|---|---|
| 200 OK | 成功，响应体通常含资源 | 最常见 |
| 201 Created | 创建成功 | REST POST 常用，带 Location |
| 204 No Content | 成功但无正文 | DELETE 常见 |
3xx 重定向
| 码 | 含义 | 注意 |
|---|---|---|
| 301 | 永久重定向 | SEO/缓存会记新地址 |
| 302 | 临时重定向 | 历史语义含糊，见下 |
| 303 | 看其它 URI（通常 GET） | POST 后 PRG 模式 |
| 304 | 缓存未修改 | 配合条件请求 |
| 307/308 | 严格保留方法的重定向 | 比 302/301 更清晰 |
旧笔记写「302：找到，但资源在另一个 URL」——方向对，但不完整。安全上要关注 开放重定向：若 Location 可被参数控制，会变成钓鱼跳板。
4xx 客户端错误
| 码 | 含义 | 常见原因 |
|---|---|---|
| 400 | 请求无法理解 | 参数/JSON 坏了 |
| 401 Unauthorized | 未认证 | 缺/错凭证；名称历史包袱，实际是 authentication |
| 403 Forbidden | 已认证但不许 | 权限不足；也可能未登录却统一返回 403 |
| 404 Not Found | 无此资源 | 路径错或故意隐藏 |
| 405 | 方法不允许 | GET/POST 用错 |
| 409 | 冲突 | 版本冲突、重复创建 |
| 429 | 太多请求 | 限流 |
安全测试里：
- 401 vs 403 泄露「用户是否存在/是否登录」的信息差
- 404 vs 403 有时被用来隐藏管理路径
5xx 服务端错误
| 码 | 含义 |
|---|---|
| 500 | 通用内部错误 |
| 502 | 网关上游坏了 |
| 503 | 不可用（过载/维护） |
| 504 | 网关超时 |
对调用方：5xx 适合重试（要退避）；4xx 多数不该盲目重试。
客户端处理建议
2xx -> 解析业务 body
3xx -> 跟随或暴露给上层（注意循环与跨域）
401 -> 走登录/刷新 token
403 -> 提示无权限，不要当「再试一次密码」
404 -> 资源不存在 UI
429 -> 指数退避
5xx -> 有限次重试 + 熔断
小结
状态码是协议层契约，不是错误文案本身。写 API 时 语义正确比全部 200 包业务码更重要；做测试时则要结合 body、头字段一起看，单独一个 302 远远不够下结论。
安全测试视角的再分类
| 观察 | 可能含义 |
|---|---|
| 同资源 401/403 切换 | 认证与授权实现细节、用户枚举面 |
| 403 与 404 混用 | 路径隐藏策略是否一致 |
| 302 到外域 | 开放重定向风险 |
| 全站 200 + 业务码 | 监控与 WAF 可能失灵 |
| 大量 429 | 限流存在，可测绕过或分布式 |
网关与微服务
边缘网关应保留真实上游状态码，或规范化时在日志中保留原始码。否则排障时「全是 502」会浪费数小时。
小结
状态码是协议契约，也是安全信号。写 API 时语义正确；做测试时结合 body、头与时间差，不单看一个三位数。
监控告警建议
- 5xx 率超阈值告警
- 401/403 突增可能是凭据泄漏扫描
- 404 突增可能是目录爆破
- 与发布事件关联，避免误报
把状态码纳入 SLI，而不只看延迟与 CPU。
延伸阅读与实践
把文章里的命令和配置放到自己的实验环境跑一遍，比只看结论更重要。建议同步记录：环境版本、失败现象、最终生效的配置。下次遇到同类问题时，检索自己的笔记往往比搜引擎更快。
若该主题涉及安全测试，请仅在明确授权的系统或官方靶场中操作，并保留测试范围与时间窗记录，避免对生产造成误伤。
对团队分享时，用「问题—影响—修复—验证」四段结构复述，有助于把个人经验沉淀为组织能力。