HTTP 状态码详解：分类拆解 + 场景排错，开发者必备（附速查表）

做接口调试、前后端联调或线上问题排查时，HTTP 状态码是 “第一信号”—— 比如看到 401 就知道是登录态失效，502 大概率是网关配置问题，304 说明静态资源命中缓存。但很多开发者只认识 200（成功）、404（找不到）、500（服务器错），对其他状态码的用法和排错逻辑一知半解，导致问题排查效率低下。今天整理完整 HTTP 状态码体系，按 “1xx 信息响应→2xx 成功→3xx 重定向→4xx 客户端错误→5xx 服务器错误” 五大类拆解，每个状态码都附 “核心含义 + 高频场景 + 排错 / 避坑技巧”，穿插 3 个实战案例（如 302 跳转导致的登录态丢失、502 错误排查），文末有 “场景速查表”，按Ctrl+F可快速定位目标状态码，收藏这篇，线上排错不用再到处搜！

一、先搞懂：HTTP 状态码的分类逻辑（避免混淆）

HTTP 状态码是 3 位数字，首位数字决定 “大类”，代表响应的核心场景，记住这个分类能快速判断问题方向：

首位数字 类别 核心含义 常见场景
1xx 信息响应 服务器已接收请求，需客户端继续操作 大文件上传分片确认、协议升级
2xx 成功响应 请求已被服务器正常处理 接口返回数据、资源创建成功
3xx 重定向 需客户端进一步跳转才能完成请求 域名迁移、登录后跳首页、缓存命中
4xx 客户端错误 请求本身有问题，服务器无法处理 参数错误、权限不足、资源不存在
5xx 服务器错误 请求没问题，但服务器处理时出错 代码 BUG、服务器过载、网关配置错误

关键原则：4xx 错看客户端（参数 / 权限 / 路径），5xx 错看服务器（日志 / 配置 / 资源），别搞反排查方向！

二、按类别拆解：高频状态码 + 场景避坑

（一）1xx 信息响应：少见但关键，主要用于 “中间确认”

1xx 状态码不常用，主要是服务器与客户端的 “中间沟通”，确保后续操作正常，重点记 2 个实用的：

状态码 核心含义 高频场景 避坑 / 排错技巧
100 继续（Continue）：服务器已接收请求头，客户端可发请求体 大文件上传（如超过 100MB 的文件）、POST 请求带大参数 场景：前端上传大文件时，浏览器先发 100 请求确认，服务器返回 100 后再发文件体；避坑：服务器若不支持，会返回 417，此时需减小请求体或改用分片上传
101 切换协议（Switching Protocols）：服务器同意切换通信协议 HTTP 升级 HTTPS、HTTP/1.1 升级 HTTP/2 场景：客户端发Upgrade: h2c请求升级 HTTP/2，服务器返回 101 后切换协议；避坑：仅用于协议升级，不要用在普通接口请求，否则会导致连接中断

（二）2xx 成功响应：核心是 “请求正常处理”，重点区分细节差异

2xx 都代表 “成功”，但不同状态码对应不同的 “成功场景”，别全用 200，用对能减少前后端误解：

状态码 核心含义 高频场景 避坑 / 排错技巧
200 成功（OK）：请求完全处理，返回对应数据 大部分 GET 接口（如查列表、查详情）、POST 接口返回结果 场景：前端调/api/user/info查用户信息，返回 200+JSON 数据；避坑：不要用 200 返 “逻辑错误”（如 “用户名已存在”），应返 400 + 错误信息，避免前端误判成功
201 创建成功（Created）：请求已创建新资源 POST 接口（如创建用户、新增文章、上传文件） 场景：调/api/article创建文章，返回 201+Location头（新文章地址）；避坑：必须返回Location头告知新资源地址，否则前端不知道去哪获取创建的资源
204 无内容（No Content）：请求成功，但无返回体 DELETE 接口（删除资源）、PUT 接口（更新资源且无需返回） 场景：调/api/user/123删除用户，返回 204（不用返回数据）；避坑：前端接 204 时要注意，响应体为空，不要尝试解析 JSON，否则会报 “语法错误”
206 部分内容（Partial Content）：仅返回资源的部分内容 大文件断点续传、分片下载（如视频、压缩包） 场景：用迅雷下载视频，客户端发Range: bytes=0-999请求前 1000 字节，服务器返回 206+Content-Range；排错：若返回 416，说明Range范围无效（如超过文件总长度），需重新获取文件大小

（三）3xx 重定向：最容易用错，重点区分 “临时 / 永久” 和 “是否保留请求方法”

3xx 状态码是 “跳转指令”，但不同码的跳转逻辑差异极大，用错会导致 “缓存混乱”“登录态丢失” 等问题，重点记 5 个高频的：

状态码 核心含义 高频场景 避坑 / 排错技巧
301 永久重定向（Moved Permanently）：资源永久迁移到新地址 域名更换（如old.com→new.com）、旧接口废弃 场景：访问old.com/article/1，返回 301 跳new.com/article/1；避坑：浏览器会永久缓存 301，改回旧地址需清缓存，临时跳转绝对不用 301！
302 临时重定向（Found）：资源临时在新地址，后续仍用原地址 登录后跳首页（如/login→/home）、临时维护页跳转 场景：用户未登录访问/home，返回 302 跳/login；避坑：POST 请求遇 302，部分浏览器会转 GET，导致请求体丢失（如登录表单提交后跳转），此时应用 307
304 未修改（Not Modified）：资源未变，直接用客户端缓存 静态资源（图片 / CSS/JS）缓存、GET 接口缓存 场景：前端第二次请求/static/css/main.css，服务器检查If-Modified-Since/ETag，发现资源未变，返回 304；排错：若预期返回 200 却出 304，检查客户端是否传了缓存头，或服务器是否正确配置缓存规则
307 临时重定向（Temporary Redirect）：严格保留原请求方法 POST/PUT 请求的临时跳转（如登录提交、表单提交） 场景：登录接口/api/login（POST）需要临时跳/api/new-login，返回 307，前端会用 POST 重发请求；避坑：替代 302 解决 “POST 转 GET” 问题，表单提交类跳转优先用 307
308 永久重定向（Permanent Redirect）：严格保留原请求方法 旧 POST 接口永久迁移到新地址 场景：/api/old-create（POST）永久迁/api/new-create，返回 308，前端用 POST 重发；避坑：比 301 更严格，适合非 GET 请求的永久迁移，普通 GET 迁址仍用 301

（四）4xx 客户端错误：问题在客户端，重点排查 “参数 / 权限 / 路径”

4xx 错是 “客户端自己的问题”，服务器没毛病，重点记 8 个高频码，覆盖 90% 客户端错误场景：

状态码 核心含义 高频场景 避坑 / 排错技巧
400 Bad Request：请求参数错误 / 格式非法 接口参数缺失（如漏传username）、JSON 格式错误、参数类型不对（如传字符串给数字字段） 排错：1. 检查请求参数是否和接口文档一致；2. 看响应体的错误提示（如 “username 不能为空”）；3. 用 Postman 重发请求验证
401 Unauthorized：未授权，需要登录验证 登录态过期（Token 失效）、未传 Authorization 头、Token 格式错误 排错：1. 检查请求头是否有Authorization: Bearer Token；2. 验证 Token 是否过期（如 JWT 解析是否报错）；3. 未登录用户访问需权限的接口（如/api/user/info）
403 Forbidden：禁止访问，已授权但无权限 普通用户访问管理员接口（如/api/admin/user）、IP 被拉黑、资源权限不足 排错：1. 确认用户角色是否有访问权限；2. 检查服务器是否有 IP 黑名单配置；3. 不要和 401 混淆（401 是 “没登录”，403 是 “登了但没权限”）
404 Not Found：资源不存在 接口路径写错（如/api/usre→/api/user）、资源已删除（如查 ID=999 的文章，实际不存在） 排错：1. 核对接口路径是否和文档一致（注意大小写，HTTP 路径默认不区分，但部分服务器配置区分）；2. 检查资源是否真的存在（如查数据库是否有该记录）；3. 不要滥用 404，资源永久删除应用 410
405 Method Not Allowed：请求方法不支持 用 GET 访问只支持 POST 的接口（如/api/login只支持 POST，却用 GET 请求）、用 DELETE 访问只支持 PUT 的接口 排错：1. 查看响应头的Allow字段（会列出支持的方法，如Allow: POST, PUT）；2. 核对接口文档的请求方法（GET/POST/PUT/DELETE）
408 Request Timeout：请求超时 客户端请求发送太慢（如大参数传输超时）、服务器处理超时（但服务器配置了短超时时间） 排错：1. 检查请求体是否过大（如超过 10MB），改用分片上传；2. 服务器端延长超时时间（如 Nginx 的proxy_connect_timeout）；3. 网络波动导致传输中断，重试一次看是否恢复
410 Gone：资源永久删除，无替代地址 旧文章被删除、废弃接口永久下线（如/api/v1/login下线，无新地址） 避坑：替代 404 的 “永久删除” 场景，让客户端知道 “这资源以后也不会有了”，而 404 是 “可能暂时找不到”；如博客删除旧文章后，访问该文章地址返回 410
413 Payload Too Large：请求体过大 POST 请求体超过服务器限制（如 Nginx 默认限制 1MB，传 2MB 的 JSON）、上传文件超过大小限制 排错：1. 检查服务器配置（如 Nginx 的client_max_body_size，改大到 20MB）；2. 大文件改用分片上传；3. 大参数拆分（如把 100 个 ID 的列表拆成多次请求）

（五）5xx 服务器错误：问题在服务器，重点排查 “日志 / 配置 / 资源”

5xx 错是 “服务器的锅”，客户端请求没问题，但服务器处理时出错，重点记 5 个高频码，覆盖线上常见故障：

状态码 核心含义 高频场景 避坑 / 排错技巧
500 Internal Server Error：服务器内部错误 代码 BUG（如空指针异常、SQL 语法错误）、未捕获的异常、配置文件错误 排错：1. 看服务器日志（如 Java 的 logback、Python 的 logging），找报错堆栈；2. 检查接口参数是否触发异常（如传 null 导致空指针）；3. 重启服务看是否临时恢复（排除内存泄漏等问题）
502 Bad Gateway：网关错误，服务器作为网关时收到无效响应 Nginx 反向代理到后端服务，后端服务挂了（如 Tomcat 崩了）、网关配置错误（如代理地址写错）、后端服务超时 排错：3 步定位法：1. 直接访问后端服务地址（绕开网关），看是否能通（如后端地址127.0.0.1:8080，用 curl 测试）；2. 检查网关配置（如 Nginx 的proxy_pass是否写错）；3. 看后端服务日志，是否有过载或崩溃信息
503 Service Unavailable：服务暂时不可用 服务器过载（CPU / 内存 100%）、服务维护中（如部署新版本时停服务）、限流触发 排错：1. 查看服务器资源（top命令看 CPU / 内存，df -h看磁盘）；2. 检查是否有维护计划；3. 看是否触发限流（如 Spring Cloud Gateway 的限流配置）；避坑：返回 503 时建议加Retry-After头（如Retry-After: 3600），告诉客户端 1 小时后重试
504 Gateway Timeout：网关超时，服务器作为网关时未及时收到后端响应 后端服务处理太慢（如复杂 SQL 执行超过 30 秒）、网关超时时间设置太短（如 Nginx 默认 1 分钟）、网络拥堵 排错：1. 延长网关超时时间（如 Nginx 的proxy_read_timeout设为 60s）；2. 优化后端接口性能（如 SQL 加索引、减少数据量）；3. 检查后端服务是否在正常处理（如看是否有执行中的线程）
505 HTTP Version Not Supported：不支持请求的 HTTP 版本 客户端用 HTTP/3 请求只支持 HTTP/1.1 的服务器、请求版本格式错误（如HTTP/2.1，实际服务器只支持 1.0/1.1/2） 排错：1. 检查客户端请求的 HTTP 版本（如浏览器 F12 看 “网络” 面板的 “协议” 列）；2. 升级服务器支持的 HTTP 版本（如 Nginx 开启 HTTP/2）；3. 客户端降级为 HTTP/1.1 请求

三、实战案例：3 个常见问题用状态码快速定位

案例 1：302 跳转导致登录态丢失（POST 转 GET 问题）

问题：前端用 POST 提交登录表单到/api/login，服务器返回 302 跳/home，但跳转后登录态消失（未保存 Cookie）。原因：部分浏览器（如 Chrome）遇到 302 时，会把 POST 请求转为 GET，导致登录表单的参数（用户名 / 密码）丢失，服务器无法生成登录态。解决：把 302 改成 307（严格保留 POST 方法），或登录成功后直接返回 200 + 跳转地址，让前端用 JS 跳转（window.location.href = '/home'）。

案例 2：静态资源频繁返回 200 而非 304（缓存失效）

问题：前端第二次请求/static/js/app.js，预期返回 304（用缓存），但实际返回 200（重新下载），浪费带宽。原因：1. 服务器未返回Last-Modified/ETag头（客户端无法发条件请求）；2. 客户端未传If-Modified-Since

详细信息：https://tool.wanxiangsucai.com/pagecode/