HTTP 状态码status code是服务器对一次请求给出的三位数结果标签成功、换地方、客户端有问题还是服务端有问题。完整表很长考试可以背上班用不上那么多。真正拖慢排障的往往是看见401和403分不清或把502当成业务错误去改前端文案。下面只收日常高频的那些并说明「该谁处理」。一、先记住四个百位状态码的第一位数字比后两位更重要。12xx请求被成功处理至少在协议语义上23xx要去别处拿或用缓存34xx请求方有问题参数、权限、路径、频率等45xx服务方或网关链路有问题排障时先看百位能迅速决定是改请求还是查服务还是跟缓存 / 重定向较劲。二、2xx成功时常用哪几个200 OK最常见。GET 到了内容PUT/PATCH 改成功且响应体里带回结果很多 API 也用 200。201 Created创建资源成功。POST 新建用户、新建订单时很常见。响应里常带新资源或Location。204 No Content成功了但没有响应体。DELETE 成功、或「已接受但无需正文」时会用。前端要注意别假定一定有 JSON 可解析。这三者够覆盖大半「成功」场景。202 Accepted已接受、异步处理中在任务队列场景会见到知道含义即可。三、3xx换地方与缓存301 / 302重定向。301更偏永久搬家302更偏临时。浏览器和爬虫行为细节不少业务上你先记住响应头里的Location才是下一个地址。304 Not Modified协商缓存命中资源没变用本地缓存即可。这不是错误。前端开发时若「接口突然没 body」先看是不是 304再看自己是否正确处理缓存头。四、4xx先查请求方400 Bad Request请求不合格JSON 坏了、缺字段、类型不对。修请求或校验提示。401 Unauthorized未认证或认证失效。简单说你还没证明「你是谁」或证明过期了。该去登录、刷新令牌而不是改业务权限文案。403 Forbidden已认证但没有权限。简单说我知道你是谁但不许做这件事。401与403是最值得分清的一对。404 Not Found路径或资源不存在。可能是 URL 写错也可能是资源已删除。对 API 设计有人用 404 表示「业务上找不到」需看项目约定。409 Conflict冲突版本不对、重复创建、状态机不允许该操作。乐观锁失败常见这个。422 Unprocessable Entity语义上懂你的请求但业务校验不过例如邮箱格式对但已被占用的规则更复杂时有的 API 用 422。与 400 的边界因项目而异对接时以接口文档为准。429 Too Many Requests被限流。该退避重试而不是立刻换参数狂刷。五、5xx先查服务与网关500 Internal Server Error服务内部未处理异常。该看服务端日志不是先怪浏览器。502 Bad Gateway网关 / 代理上游收到无效响应。常是上游挂了、协议不对、连接被掐。503 Service Unavailable服务暂时不可用维护、过载、主动熔断。可重试但要有间隔与上限。504 Gateway Timeout网关等上游超时。查上游耗时、超时配置、是否慢查询而不是只加大前端fetch等待。六、前后端各自怎么用6.1 写接口时1成功用 2xx并稳定一种风格创建用 201 还是 200项目内统一2鉴权失败用 401权限不足用 403别混3校验失败用 400 或 422响应体里给出可展示的错误信息4别把所有错误都打成 500未捕获异常才是 500下面是一个最小响应示例。HTTP/1.1 401 Unauthorized Content-Type: application/json {error:token_expired,message:请重新登录}上面代码中状态码告诉客户端「认证层失败」body 告诉产品文案怎么写。两者分工不要只靠 body 里的code: 200假装成功。6.2 写前端时1先分支百位再处理具体码2401走刷新令牌或登录态清理3403展示无权限不要当成未登录死循环跳转4429 / 503 / 504有限次退避避免雪崩5502 / 500给可重试与报错入口把request id留下下面是一个极简分支示意。if(res.status401)returnrefreshOrLogin();if(res.status403)returnshowForbidden();if(res.status429)returnretryAfter(res.headers.get(Retry-After));if(res.status500)returnshowServerError();上面代码中401 与 403 分开5xx 合并展示可以但日志里仍应记下具体状态码。七、常见误区1业务失败也返回 200只在 JSON 里写success: false能跑但缓存、监控、客户端中间件都会变难。新项目尽量用状态码表达协议层结果。2看见 404 就只查前端路由API 的 404 与页面路由 404 不是同一层。先分清是文档站、SPA 路由还是接口路径。3401 / 403 混用会导致「有权限的用户被踢去登录」或「未登录用户看到无权限」。4把 502 / 504 当业务异常提示给用户「参数错误」文案误导排障更慢。5背冷门码却分不清百位418可以当梗排障时 4xx / 5xx 的分流更要紧。八、小结日常够用的集合其实不大2xx2002012043xx301/3023044xx4004014034044094224295xx500502503504先看百位再看这一小撮常用码并分清「改请求」还是「查服务」。完整表留给搜索工作台只留会用到的。完 HTTP 状态码：只记你真正用得到的那些
HTTP 状态码status code是服务器对一次请求给出的三位数结果标签成功、换地方、客户端有问题还是服务端有问题。完整表很长考试可以背上班用不上那么多。真正拖慢排障的往往是看见401和403分不清或把502当成业务错误去改前端文案。下面只收日常高频的那些并说明「该谁处理」。一、先记住四个百位状态码的第一位数字比后两位更重要。12xx请求被成功处理至少在协议语义上23xx要去别处拿或用缓存34xx请求方有问题参数、权限、路径、频率等45xx服务方或网关链路有问题排障时先看百位能迅速决定是改请求还是查服务还是跟缓存 / 重定向较劲。二、2xx成功时常用哪几个200 OK最常见。GET 到了内容PUT/PATCH 改成功且响应体里带回结果很多 API 也用 200。201 Created创建资源成功。POST 新建用户、新建订单时很常见。响应里常带新资源或Location。204 No Content成功了但没有响应体。DELETE 成功、或「已接受但无需正文」时会用。前端要注意别假定一定有 JSON 可解析。这三者够覆盖大半「成功」场景。202 Accepted已接受、异步处理中在任务队列场景会见到知道含义即可。三、3xx换地方与缓存301 / 302重定向。301更偏永久搬家302更偏临时。浏览器和爬虫行为细节不少业务上你先记住响应头里的Location才是下一个地址。304 Not Modified协商缓存命中资源没变用本地缓存即可。这不是错误。前端开发时若「接口突然没 body」先看是不是 304再看自己是否正确处理缓存头。四、4xx先查请求方400 Bad Request请求不合格JSON 坏了、缺字段、类型不对。修请求或校验提示。401 Unauthorized未认证或认证失效。简单说你还没证明「你是谁」或证明过期了。该去登录、刷新令牌而不是改业务权限文案。403 Forbidden已认证但没有权限。简单说我知道你是谁但不许做这件事。401与403是最值得分清的一对。404 Not Found路径或资源不存在。可能是 URL 写错也可能是资源已删除。对 API 设计有人用 404 表示「业务上找不到」需看项目约定。409 Conflict冲突版本不对、重复创建、状态机不允许该操作。乐观锁失败常见这个。422 Unprocessable Entity语义上懂你的请求但业务校验不过例如邮箱格式对但已被占用的规则更复杂时有的 API 用 422。与 400 的边界因项目而异对接时以接口文档为准。429 Too Many Requests被限流。该退避重试而不是立刻换参数狂刷。五、5xx先查服务与网关500 Internal Server Error服务内部未处理异常。该看服务端日志不是先怪浏览器。502 Bad Gateway网关 / 代理上游收到无效响应。常是上游挂了、协议不对、连接被掐。503 Service Unavailable服务暂时不可用维护、过载、主动熔断。可重试但要有间隔与上限。504 Gateway Timeout网关等上游超时。查上游耗时、超时配置、是否慢查询而不是只加大前端fetch等待。六、前后端各自怎么用6.1 写接口时1成功用 2xx并稳定一种风格创建用 201 还是 200项目内统一2鉴权失败用 401权限不足用 403别混3校验失败用 400 或 422响应体里给出可展示的错误信息4别把所有错误都打成 500未捕获异常才是 500下面是一个最小响应示例。HTTP/1.1 401 Unauthorized Content-Type: application/json {error:token_expired,message:请重新登录}上面代码中状态码告诉客户端「认证层失败」body 告诉产品文案怎么写。两者分工不要只靠 body 里的code: 200假装成功。6.2 写前端时1先分支百位再处理具体码2401走刷新令牌或登录态清理3403展示无权限不要当成未登录死循环跳转4429 / 503 / 504有限次退避避免雪崩5502 / 500给可重试与报错入口把request id留下下面是一个极简分支示意。if(res.status401)returnrefreshOrLogin();if(res.status403)returnshowForbidden();if(res.status429)returnretryAfter(res.headers.get(Retry-After));if(res.status500)returnshowServerError();上面代码中401 与 403 分开5xx 合并展示可以但日志里仍应记下具体状态码。七、常见误区1业务失败也返回 200只在 JSON 里写success: false能跑但缓存、监控、客户端中间件都会变难。新项目尽量用状态码表达协议层结果。2看见 404 就只查前端路由API 的 404 与页面路由 404 不是同一层。先分清是文档站、SPA 路由还是接口路径。3401 / 403 混用会导致「有权限的用户被踢去登录」或「未登录用户看到无权限」。4把 502 / 504 当业务异常提示给用户「参数错误」文案误导排障更慢。5背冷门码却分不清百位418可以当梗排障时 4xx / 5xx 的分流更要紧。八、小结日常够用的集合其实不大2xx2002012043xx301/3023044xx4004014034044094224295xx500502503504先看百位再看这一小撮常用码并分清「改请求」还是「查服务」。完整表留给搜索工作台只留会用到的。完