HTTP状态码完整列表及含义：1xx、2xx、3xx、4xx、5xx详解

在网站开发、API接口开发、前后端联调和服务器运维过程中，经常会遇到各种HTTP状态码。

例如：

200 OK
301 Moved Permanently
302 Found
304 Not Modified
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
405 Method Not Allowed
409 Conflict
422 Unprocessable Content
429 Too Many Requests
500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout

这些状态码并不是服务器随意返回的数字，而是HTTP协议用于描述请求处理结果的重要组成部分。

通过HTTP状态码，客户端可以快速判断：

• 请求是否成功
• 是否需要重定向
• 请求参数是否存在问题
• 是否需要身份认证
• 是否没有访问权限
• 请求资源是否不存在
• 服务器是否发生错误
• 上游服务是否不可用
• 是否触发限流

本文将系统介绍HTTP状态码的五大类别，并整理常见状态码的具体含义、使用场景和开发中的排查方法。

一、什么是HTTP状态码？

HTTP状态码是服务器返回HTTP响应时，用来表示请求处理结果的三位数字。

一个典型的HTTP响应可能如下：

HTTP/1.1 200 OK
Content-Type: application/json

{
  "success": true
}

其中：

200

就是HTTP状态码。

而：

OK

是状态码对应的原因短语。

HTTP状态码通常由三个数字组成：

2xx

其中第一位数字表示状态码类别。

二、HTTP状态码五大类别

HTTP状态码主要分为五大类别：

可以简单记忆：

1xx → 正在处理 / 提示信息

2xx → 成功

3xx → 重定向

4xx → 客户端请求存在问题

5xx → 服务器处理存在问题

三、1xx 信息响应状态码

1xx状态码表示：

请求已经收到，服务器需要继续处理。

这类状态码通常不是最终响应。

常见1xx状态码包括：

100 Continue

100 Continue表示服务器已经收到请求头，并且客户端可以继续发送请求体。

典型场景是客户端发送较大的请求。

例如：

POST /upload HTTP/1.1
Expect: 100-continue

服务器返回：

HTTP/1.1 100 Continue

客户端随后继续发送请求数据。

这个机制可以避免客户端在服务器已经拒绝请求的情况下，提前发送大量请求体。

101 Switching Protocols

101表示服务器同意切换通信协议。

经典应用场景：

WebSocket协议升级。

例如：

GET /chat HTTP/1.1
Upgrade: websocket
Connection: Upgrade

服务器可能返回：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade

随后通信从HTTP升级为WebSocket。

102 Processing

102 Processing主要用于表示服务器已经收到请求，但处理仍然需要继续。

它最初与WebDAV相关。

在普通Web API开发中并不常见。

103 Early Hints

103 Early Hints用于提前向客户端发送一些响应头信息。

例如服务器正式生成页面之前，可以提前告诉浏览器：

Link: </style.css>; rel=preload

浏览器可以提前加载资源，从而改善页面加载性能。

四、2xx 成功状态码

2xx表示：

请求已经成功处理。

这是开发过程中最常见的一类状态码。

常见状态码包括：

五、200 OK

200 OK表示请求成功。

这是Web开发中最常见的HTTP状态码。

例如：

GET /api/users/1

服务器成功返回用户数据：

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 1,
  "name": "Tom"
}

常见场景：

• GET请求成功
• POST请求成功
• PUT请求成功
• 查询数据成功
• 页面访问成功

六、201 Created

201 Created表示：

请求成功，并且创建了新的资源。

最常见于REST API。

例如：

POST /api/users

服务器创建用户成功：

HTTP/1.1 201 Created

响应可能返回：

{
  "id": 1001,
  "name": "Tom"
}

典型应用：

POST /users
POST /orders
POST /products

如果请求的主要作用是创建资源，201通常比单纯返回200更加准确。

七、202 Accepted

202 Accepted表示：

服务器已经接受请求，但请求对应的任务还没有完成。

这非常适合异步任务。

例如：

用户上传视频
       ↓
服务器创建转码任务
       ↓
立即返回202
       ↓
后台继续转码

响应：

{
  "taskId": "abc123",
  "status": "processing"
}

常见场景：

• 视频转码
• 图片处理
• AI任务
• 大文件处理
• 批量数据导入
• 异步消息处理

八、203 Non-Authoritative Information

203表示服务器返回的信息不是原始服务器提供的。

这种状态码在普通Web开发中比较少见。

多数业务系统通常不会主动使用203。

九、204 No Content

204 No Content表示：

请求成功，但是响应没有内容。

例如删除资源：

DELETE /api/users/100

服务器成功删除：

HTTP/1.1 204 No Content

响应体为空。

需要注意：

204响应不能包含正常的响应内容。

前端开发中经常遇到：

const response = await fetch("/api/users/100");

如果服务器返回204，就不要强制执行：

await response.json();

否则可能出现解析错误。

十、205 Reset Content

205 Reset Content表示请求成功，并要求客户端重置当前内容。

例如某些表单提交成功之后，可以让客户端清空表单。

不过实际项目中使用频率比较低。

十一、206 Partial Content

206 Partial Content表示：

服务器只返回请求资源的一部分内容。

它通常和HTTP Range请求配合使用。

例如：

Range: bytes=0-999

服务器可能返回：

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-999/10000

常见应用：

• 视频播放
• 音频播放
• 大文件下载
• 断点续传
• 文件分片下载

十二、207 Multi-Status

207 Multi-Status主要用于WebDAV。

它可以在一次请求中返回多个资源的处理结果。

例如：

文件A → 成功
文件B → 失败
文件C → 成功

服务器可以通过一个响应返回多个资源的状态。

普通REST API中并不常见。

十三、208 Already Reported

208 Already Reported同样主要与WebDAV相关。

它用于避免在多状态响应中重复报告已经列出的资源。

普通Web开发中很少使用。

十四、226 IM Used

226 IM Used属于HTTP增量响应相关机制。

它用于表示服务器已经成功完成请求，并返回经过增量编码处理后的结果。

在普通Web开发中非常少见。

十五、3xx 重定向状态码

3xx表示：

客户端需要进一步操作才能完成请求。

最常见的是URL重定向。

常见状态码：

十六、300 Multiple Choices

300表示服务器存在多个可选资源。

客户端可以根据服务器返回的信息选择合适的资源。

实际Web项目中比较少见。

十七、301 Moved Permanently

301表示：

资源已经永久移动到新的URL。

例如：

旧地址：

https://example.com/old

        ↓ 301

新地址：

https://example.com/new

服务器：

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new

301经常用于：

• 网站域名迁移
• HTTP跳转HTTPS
• URL结构调整
• 页面永久迁移
• SEO地址变更

十八、302 Found

302表示：

当前资源临时位于另一个URL。

例如：

/login
   ↓
302
   ↓
/user/login

302常用于临时跳转。

不过在涉及POST等请求方法时，如果需要明确保持原始请求方法，通常应该考虑307。

十九、303 See Other

303用于告诉客户端：

可以通过另一个URL获取结果。

经典场景是：

POST提交表单
      ↓
303
      ↓
GET结果页面

这种模式可以避免用户刷新页面时重复提交表单。

二十、304 Not Modified

304是Web缓存中非常重要的状态码。

它表示：

客户端缓存的资源没有发生变化，可以继续使用本地缓存。

例如浏览器已经缓存：

style.css

再次请求时可能携带：

If-None-Match: "abc123"

服务器判断资源没有变化：

HTTP/1.1 304 Not Modified

浏览器继续使用本地缓存。

因此：

304通常不是错误，而是正常的缓存机制。

二十一、307 Temporary Redirect

307表示临时重定向。

它与302比较相似，但一个重要区别是：

307要求客户端保持原始请求方法和请求体。

例如：

POST /api/login

如果返回307：

POST /api/login
   ↓
307
   ↓
POST /new-login

而不是自动变成GET。

因此对于需要严格保持HTTP方法的场景，307更加明确。

二十二、308 Permanent Redirect

308表示永久重定向。

它与301类似，但会明确保持原始HTTP方法。

例如：

POST /api/order

返回：

308

客户端继续：

POST /new-api/order

因此：

301和308都是永久重定向，但308更明确要求保持请求方法。

二十三、301、302、307、308怎么选择？

可以简单理解：

如果是普通网页URL永久迁移：

301

非常常见。

如果需要严格保持POST、PUT等请求方法：

307
308

通常更加明确。

二十四、4xx 客户端错误状态码

4xx表示：

请求本身存在问题，或者客户端没有权限完成请求。

常见状态码包括：

二十五、400 Bad Request

400表示：

服务器无法理解或处理客户端发送的请求。

常见原因：

• JSON格式错误
• 参数类型错误
• 参数缺失
• 请求格式错误
• URL格式错误
• 请求体无法解析

例如接口要求：

{
  "age": 20
}

客户端却发送：

{
  "age": "abc"
}

服务器可能返回：

400 Bad Request

二十六、401 Unauthorized

401通常表示：

请求需要身份认证，或者提供的认证信息无效。

例如API要求：

Authorization: Bearer token

但是客户端没有提供Token：

GET /api/user

服务器可能返回：

401 Unauthorized

常见原因：

• 没有登录
• Token不存在
• Token过期
• Token无效
• API Key错误

二十七、401和403有什么区别？

这是开发中非常常见的问题。

简单理解：

401
↓
你是谁？
↓
需要认证

403
↓
我知道你是谁
↓
但你没有权限

例如：

未登录访问管理后台
→ 401

普通用户访问管理员接口
→ 403

不过实际系统中，具体语义也可能根据认证框架和安全策略有所不同。

二十八、402 Payment Required

402表示：

Payment Required。

这个状态码最初为未来支付场景预留。

目前并不是所有支付系统都会严格使用402。

一些：

• SaaS
• API服务
• AI服务
• 订阅服务

可能会使用402表示：

余额不足
订阅已过期
需要购买套餐

但具体含义取决于服务设计。

二十九、403 Forbidden

403表示：

服务器理解请求，但拒绝提供访问权限。

常见原因：

• 没有访问权限
• IP被禁止
• 用户角色不足
• 文件权限不足
• WAF拦截
• Nginx访问限制
• 目录访问被禁止

例如：

普通用户
   ↓
访问管理员接口
   ↓
403

三十、404 Not Found

404是互联网中最常见的HTTP状态码之一。

表示：

请求的资源不存在。

例如：

GET /articles/abc

但是服务器没有这个页面：

404 Not Found

常见原因：

• URL写错
• 页面被删除
• API路径错误
• 路由配置错误
• 文件不存在
• 前端路由没有配置
• Nginx配置错误

三十一、405 Method Not Allowed

405表示：

URL存在，但当前HTTP请求方法不允许。

例如接口只允许：

POST /api/login

客户端却发送：

GET /api/login

服务器可能返回：

405 Method Not Allowed

常见问题：

GET → POST接口
POST → GET接口
PUT → POST接口
DELETE → GET接口

因此遇到405时，需要检查：

URL和HTTP Method是否匹配。

三十二、406 Not Acceptable

406表示：

服务器无法生成满足客户端要求的响应格式。

例如客户端通过：

Accept: application/xml

要求XML响应，但是服务器只能返回JSON。

这种情况下可能返回406。

现代REST API中不算特别常见。

三十三、407 Proxy Authentication Required

407表示：

客户端需要通过代理服务器认证。

它类似于401，但认证对象是：

Proxy。

通常出现在企业代理、网络代理等环境。

三十四、408 Request Timeout

408表示：

服务器等待客户端请求超时。

例如客户端建立连接之后迟迟没有发送完整请求。

服务器等待超过限制后：

408 Request Timeout

需要注意：

408和504并不是同一种超时。

408主要是服务器等待客户端请求数据超时。

504主要是网关等待上游服务器响应超时。

三十五、409 Conflict

409表示：

请求与当前资源状态发生冲突。

例如：

创建用户名：
admin

但是数据库中已经存在：

admin

服务器可能返回：

409 Conflict

常见场景：

• 重复创建资源
• 数据版本冲突
• 并发修改
• 状态冲突
• 唯一约束冲突

三十六、410 Gone

410表示：

资源已经永久删除，并且服务器明确知道该资源已经不存在。

与404相比：

404
↓
不知道资源是否曾经存在

而：

410
↓
明确知道资源已经永久删除

对于SEO和旧URL管理来说，两者含义存在区别。

三十七、411 Length Required

411表示：

请求缺少服务器要求的Content-Length。

现在HTTP/1.1及现代Web环境中较少直接遇到。

三十八、412 Precondition Failed

412表示：

请求中提供的前置条件没有满足。

常见于：

If-Match
If-Unmodified-Since

等条件请求。

例如：

客户端保存的是版本A
服务器已经更新到版本B

客户端再次提交更新时：

If-Match: "version-A"

服务器发现版本已经变化：

412 Precondition Failed

这可以用于避免覆盖其他用户已经修改的数据。

三十九、413 Content Too Large

413表示：

请求内容超过服务器允许的大小。

常见于：

• 文件上传
• 图片上传
• 视频上传
• JSON请求体
• 批量数据提交

例如Nginx：

client_max_body_size 10M;

客户端上传超过10MB：

413 Content Too Large

常见排查位置：

浏览器
 ↓
Nginx
 ↓
Gateway
 ↓
后端服务

任何一层都可能限制请求大小。

四十、414 URI Too Long

414表示：

请求URI过长。

例如把大量数据直接放到GET URL：

/api/search?a=xxxxxxxxxxxxxxxx...

当URL过长时，服务器可能返回414。

如果需要传输大量数据，可以考虑：

POST + Request Body

而不是无限增加URL长度。

四十一、415 Unsupported Media Type

415表示：

服务器不支持客户端发送的数据格式。

这是前后端开发中非常常见的问题。

例如后端要求：

Content-Type: application/json

客户端却发送：

Content-Type: multipart/form-data

或者：

Content-Type: application/x-www-form-urlencoded

就可能出现415。

典型问题：

Spring Boot @RequestBody
        +
错误的Content-Type
        ↓
415

四十二、416 Range Not Satisfiable

416表示：

客户端请求的Range范围无法满足。

例如文件只有：

0-999

客户端请求：

Range: bytes=5000-6000

服务器无法满足，就可能返回416。

常见于：

• 视频播放
• 断点下载
• 大文件传输

四十三、417 Expectation Failed

417表示服务器无法满足请求头中的Expect条件。

实际开发中较少直接遇到。

四十四、418 I'm a teapot

418 I'm a teapot是HTTP历史中非常著名的趣味状态码。

它来自：

HTCPCP（Hyper Text Coffee Pot Control Protocol）

主要是一个程序员彩蛋。

很多Web框架、Demo或者网站会把418作为：

彩蛋

而不是正常业务错误码。

四十五、421 Misdirected Request

421表示请求被发送到了无法为该请求生成响应的服务器。

它可能与：

• HTTP/2
• TLS
• 多域名
• 代理
• 连接复用

等场景有关。

普通业务开发中不常见。

四十六、422 Unprocessable Content

422表示：

请求格式本身正确，但是服务器无法处理请求内容。

例如：

{
  "email": "abc"
}

JSON格式没有问题。

但是业务规则要求：

email必须是合法邮箱

因此服务器无法处理。

可能返回：

422 Unprocessable Content

常用于：

• 参数验证
• 表单校验
• REST API
• 业务字段验证

四十七、423 Locked

423表示：

请求的资源当前处于锁定状态。

主要与WebDAV有关。

普通业务API可以根据自身设计使用类似语义，但不应把423误认为普通数据库锁异常的标准返回码。

四十八、424 Failed Dependency

424表示：

当前请求依赖的另一个操作失败。

主要用于WebDAV。

普通REST API比较少见。

四十九、425 Too Early

425用于表示服务器不愿意处理过早发送的请求。

主要与：

• TLS
• 0-RTT
• 重放攻击风险

等机制相关。

普通Web业务中比较少见。

五十、426 Upgrade Required

426表示：

客户端需要升级或切换协议。

例如服务器要求客户端使用：

HTTPS

或者其他更高版本协议。

实际应用中并不如301、302常见。

五十一、428 Precondition Required

428表示：

服务器要求请求必须包含前置条件。

它常用于防止并发修改造成数据覆盖。

例如：

用户A读取数据
用户B修改数据
用户A提交旧数据

服务器可以要求：

If-Match

来确认客户端操作的是最新版本。

五十二、429 Too Many Requests

429是现代Web API中非常重要的状态码。

它表示：

客户端请求过于频繁，触发了限流策略。

例如：

1分钟最多100次请求

客户端发送：

101次

服务器返回：

429 Too Many Requests

常见场景：

• API限流
• 登录防暴力破解
• 爬虫限制
• AI API调用限制
• 短信接口限制
• IP限流

服务器还可以通过：

Retry-After

告诉客户端应该等待多久再重试。

五十三、431 Request Header Fields Too Large

431表示：

请求头字段过大。

常见原因：

• Cookie过多
• Cookie过大
• Authorization信息过长
• 自定义Header过多
• 单个Header字段过大

例如：

Cookie
 ↓
越来越大
 ↓
请求头超过服务器限制
 ↓
431

排查时可以重点查看：

Cookie
Authorization
自定义Header

五十四、451 Unavailable For Legal Reasons

451表示：

由于法律原因，资源不可用。

例如：

• 法律限制
• 司法命令
• 地区访问限制
• 内容监管

它的数字来源与文学作品《华氏451度》有关。

五十五、5xx 服务器错误状态码

5xx表示：

服务器在处理请求时发生了错误，或者无法完成请求。

常见状态码：

五十六、500 Internal Server Error

500是最常见的服务器错误之一。

表示：

服务器处理请求时发生了未预期的内部错误。

例如：

前端
 ↓
API
 ↓
Java服务
 ↓
NullPointerException
 ↓
500

常见原因：

• 空指针异常
• 数据库异常
• 代码异常
• 未处理异常
• 配置错误
• 第三方服务异常

遇到500时，最重要的是：

查看服务器日志。

浏览器中的500通常只是结果，不是根本原因。

五十七、501 Not Implemented

501表示：

服务器不支持完成请求所需的功能。

例如客户端请求某个服务器不支持的HTTP方法。

实际Web开发中相对少见。

五十八、502 Bad Gateway

502是微服务和Nginx环境中非常常见的状态码。

它表示：

网关或代理服务器从上游服务器收到无效响应。

典型架构：

浏览器
   ↓
Nginx
   ↓
Gateway
   ↓
Service

如果：

Nginx
   ↓
Gateway连接异常

可能出现：

502 Bad Gateway

常见原因：

• 上游服务没有启动
• 服务端口错误
• Docker容器没有启动
• Gateway地址配置错误
• Nginx反向代理配置错误
• 上游连接被拒绝
• 服务异常退出

五十九、503 Service Unavailable

503表示：

服务当前无法处理请求。

常见原因：

• 服务正在启动
• 服务正在维护
• 服务过载
• 服务实例全部不可用
• Kubernetes Pod异常
• 服务暂时不可用

例如：

用户
 ↓
Nginx
 ↓
负载均衡
 ↓
没有可用实例
 ↓
503

如果服务只是暂时不可用，可以结合：

Retry-After

告诉客户端稍后重试。

六十、504 Gateway Timeout

504表示：

网关等待上游服务器响应超时。

例如：

浏览器
 ↓
Nginx
 ↓
Gateway
 ↓
后端服务
 ↓
数据库

后端执行一个耗时很长的SQL：

数据库查询
      ↓
超过网关超时时间
      ↓
504

常见原因：

• 后端接口执行太慢
• SQL查询慢
• 第三方API响应慢
• 网络连接慢
• Gateway超时
• Nginx超时

六十一、502和504有什么区别？

这是排查线上问题时非常重要的区别。

简单理解：

502
↓
上游返回了异常/无效响应

504
↓
上游迟迟没有响应
↓
等待超时

例如：

服务根本没启动
→ 502

服务启动了，但处理请求超过超时时间
→ 504

实际情况可能更加复杂，需要结合：

• Nginx日志
• Gateway日志
• 应用日志
• Docker日志
• Kubernetes日志

综合判断。

六十二、505 HTTP Version Not Supported

505表示：

服务器不支持客户端使用的HTTP版本。

例如服务器不支持客户端要求的某个HTTP协议版本。

现代Web环境中比较少见。

六十三、506 Variant Also Negotiates

506与HTTP内容协商机制有关。

主要表示服务器配置存在内容协商相关问题。

普通Web开发中非常少见。

六十四、507 Insufficient Storage

507主要与WebDAV有关。

表示服务器无法完成请求，因为没有足够的存储空间。

例如：

磁盘空间不足

也可能出现类似：

No space left on device

需要检查服务器：

df -h

六十五、508 Loop Detected

508主要与WebDAV相关。

表示服务器在处理请求时检测到循环。

普通Web API中很少遇到。

六十六、510 Not Extended

510表示服务器需要进一步扩展请求才能完成操作。

实际应用中比较少见。

六十七、511 Network Authentication Required

511表示：

客户端需要通过网络认证才能访问资源。

常见于：

• 公共Wi-Fi
• 门户认证
• 网络接入认证

例如连接酒店Wi-Fi之后：

连接Wi-Fi
 ↓
需要登录
 ↓
511

六十八、最常见HTTP状态码速查表

如果只是日常开发，最需要记住的是下面这些：

六十九、前后端开发最常见的HTTP错误

实际开发中，下面这些状态码出现频率非常高。

400：请求参数问题

检查：

JSON
参数名称
参数类型
必填参数
URL

401：Token问题

检查：

Authorization
Bearer Token
Token是否过期
登录状态

403：权限问题

检查：

用户角色
接口权限
RBAC
IP限制
Nginx
WAF

404：地址问题

检查：

URL
Controller路径
Gateway路由
Nginx
前端路由
文件路径

405：HTTP方法问题

检查：

GET
POST
PUT
DELETE

是否和后端接口定义一致。

415：Content-Type问题

检查：

Content-Type: application/json

是否与后端接收方式匹配。

例如：

@RequestBody

通常对应JSON请求体。

422：业务参数验证问题

检查：

字段格式
字段长度
枚举值
业务规则
必填字段

429：请求太频繁

检查：

API限流
IP限流
用户限流
Token限流
网关限流

500：后端代码问题

检查：

应用日志
异常堆栈
数据库
第三方服务
配置文件

502：网关和上游服务问题

检查：

服务是否启动
端口是否正确
容器是否运行
Gateway配置
Nginx配置
网络连接

503：服务不可用

检查：

实例数量
服务健康状态
CPU
内存
连接池
维护状态

504：超时问题

检查：

SQL执行时间
接口执行时间
第三方API
Nginx timeout
Gateway timeout
数据库连接

七十、HTTP状态码排查思路

遇到HTTP错误时，不要只盯着浏览器。

可以按照请求链路逐层排查：

浏览器
   ↓
CDN
   ↓
Nginx
   ↓
Gateway
   ↓
微服务
   ↓
数据库
   ↓
第三方服务

首先查看：

HTTP状态码

然后查看：

Response Body

接下来查看：

浏览器Network

再查看：

Nginx日志

然后：

Gateway日志

最后：

后端应用日志
数据库日志

这样比单纯反复刷新页面更容易定位问题。

七十一、浏览器如何查看HTTP状态码？

Chrome等浏览器可以打开开发者工具。

通常：

F12

然后进入：

Network

刷新页面。

选择具体请求后，可以看到：

Request URL
Request Method
Status Code
Response Headers
Request Headers
Response

例如：

Status Code: 200 OK

或者：

Status Code: 404 Not Found

这对于前端排查API问题非常重要。

七十二、使用curl查看HTTP状态码

Linux、macOS以及很多Windows环境都可以使用curl。

例如：

curl -I https://example.com

可以查看响应头。

可能得到：

HTTP/2 200
content-type: text/html

如果页面不存在：

HTTP/2 404

如果发生重定向：

HTTP/2 301
location: https://www.example.com/

七十三、使用curl查看完整HTTP响应

例如：

curl -i https://example.com/api/users

可以同时看到：

HTTP状态码
响应头
响应体

这对于API调试非常有用。

七十四、API测试中的HTTP状态码

在开发REST API时，可以根据操作选择合理的状态码。

例如：

查询成功

GET /users/1

200 OK

创建成功

POST /users

201 Created

删除成功

DELETE /users/1

204 No Content

未登录

401 Unauthorized

没有权限

403 Forbidden

数据不存在

404 Not Found

参数验证失败

422 Unprocessable Content

请求冲突

409 Conflict

请求过于频繁

429 Too Many Requests

这样API语义会更加清晰。

七十五、HTTP状态码和业务状态码不要混淆

很多后端项目会同时存在：

HTTP状态码

和：

{
  "code": 10001,
  "message": "用户名不存在"
}

这里的：

10001

并不是HTTP状态码。

HTTP状态码可能仍然是：

200

因此开发过程中需要明确：

HTTP Status

和：

Business Code

是两套不同的状态体系。

七十六、API应该全部返回200吗？

不建议。

例如：

用户没有登录

如果仍然返回：

200

然后：

{
  "code": 401,
  "message": "未登录"
}

虽然技术上可以实现，但HTTP语义不够清晰。

更标准的设计通常是：

HTTP 401

再在响应体中提供业务错误信息。

同理：

资源不存在
→ 404

没有权限
→ 403

请求参数错误
→ 400 / 422

服务器异常
→ 500

七十七、HTTP状态码选择建议

可以按照下面的思路选择。

请求成功？
   ↓
是
   ↓
创建资源？
 ├─ 是 → 201
 └─ 否 → 200

没有响应内容？
   ↓
204

需要重定向？
   ↓
301 / 302 / 307 / 308

请求本身错误？
   ↓
400

需要登录？
   ↓
401

没有权限？
   ↓
403

资源不存在？
   ↓
404

HTTP方法错误？
   ↓
405

资源冲突？
   ↓
409

请求数据过大？
   ↓
413

Content-Type错误？
   ↓
415

参数无法处理？
   ↓
422

请求过于频繁？
   ↓
429

服务器异常？
   ↓
500

网关无法获得有效上游响应？
   ↓
502

服务暂时不可用？
   ↓
503

网关等待上游超时？
   ↓
504

七十八、HTTP状态码完整分类总结

最终可以把HTTP状态码记成下面这张表：

其中开发者最应该掌握：

200
201
204

301
302
304
307
308

400
401
403
404
405
409
413
415
422
429

500
502
503
504

七十九、HTTP状态码快速记忆方法

如果刚开始学习HTTP，可以先记住：

1xx
↓
有信息，继续处理

2xx
↓
成功

3xx
↓
跳转

4xx
↓
请求有问题

5xx
↓
服务器有问题

再记住几个最重要的：

200 → 成功
201 → 创建成功
204 → 成功但没有内容

301 → 永久跳转
302 → 临时跳转
304 → 使用缓存

400 → 请求错误
401 → 没登录
403 → 没权限
404 → 找不到
405 → 方法错误
409 → 冲突
415 → 格式不支持
422 → 参数无法处理
429 → 请求太多

500 → 服务内部错误
502 → 网关错误
503 → 服务不可用
504 → 网关超时

掌握这些状态码，就可以覆盖绝大多数Web开发和API开发中的实际场景。

八十、总结

HTTP状态码是Web开发中非常基础但又非常重要的知识。

它通过三位数字告诉客户端：

当前HTTP请求到底发生了什么。

五大类别分别是：

1xx → 信息响应
2xx → 成功
3xx → 重定向
4xx → 客户端错误
5xx → 服务器错误

其中：

200

表示请求成功；

201

通常表示资源创建成功；

204

表示请求成功但没有响应内容；

301 / 302 / 307 / 308

用于不同类型的重定向；

304

用于缓存协商；

400

通常表示请求本身存在问题；

401

通常表示需要身份认证；

403

表示没有访问权限；

404

表示资源不存在；

405

表示HTTP方法不允许；

409

表示资源状态发生冲突；

415

表示请求的数据格式不受支持；

422

表示请求格式正确，但内容无法通过处理或验证；

429

表示请求过于频繁；

500

表示服务器内部出现异常；

502

通常表示网关从上游服务获得了无效响应；

503

表示服务暂时无法处理请求；

504

表示网关等待上游服务响应超时。

在实际开发中，遇到HTTP错误不要只看一个数字。

应该结合：

• 浏览器Network
• Request URL
• Request Method
• Request Headers
• Response Headers
• Response Body
• Nginx日志
• Gateway日志
• 后端应用日志
• 数据库日志

进行完整排查。

掌握HTTP状态码，不仅能够帮助开发者快速定位前后端接口问题，也能够帮助理解浏览器、Nginx、网关、微服务和API之间的数据通信过程。