HTTP 状态码全谱
基于 HTTP 标准（RFC 9110 语义）· 核于 2026-06
速查
- 五大类一句话：
1xx信息（请求已收到，继续处理）、2xx成功（已被理解并接受）、3xx重定向（需进一步动作才能完成）、4xx客户端错误（请求有问题）、5xx服务端错误（服务器处理失败）。 - 首位即语义：只看第一位数字就能判断大方向；前端拿到响应先看
status落在哪一类，再细究具体码。 - 永久 vs 临时重定向：
301/308永久（浏览器/搜索引擎会缓存并替换书签），302/307临时（不应被缓存）。 - 重定向是否保留请求方法：
307/308严格保留原方法与请求体；301/302历史上常被客户端改写成GET；303强制改为 GET（POST 提交后重定向的 PRG 模式专用）。 304 Not Modified：协商缓存命中，告诉浏览器"用本地副本"，响应无体——前端在 Network 面板看到它说明缓存生效（本页只讲语义，机制见缓存页）。401≠403：401 Unauthorized实为"未认证"（没登录/凭证无效，该带WWW-Authenticate）；403 Forbidden是"已认证但无权"（登录了也不让访问）——前端高频混淆。429 Too Many Requests：被限流，配合Retry-After告知多久后可重试；前端应据此退避而非立即重试。4xx怪你、5xx怪服务器：4xx改请求才有救（补参数、补 token），5xx重试或等服务恢复（500 通用、502 网关坏、503 不可用、504 上游超时）。204 No Content：成功但无返回体（常见于DELETE、表单提交无需回数据）；前端别去.json()解析空响应体。206 Partial Content：范围请求（断点续传、视频拖动进度条）的成功响应，配合Range首部。103 Early Hints（较新）：正式响应前先下发Link首部，让浏览器提前preload/preconnect，抢跑关键资源加载。
1xx 信息响应
临时响应：服务器已收到请求、正在处理，最终结果还在后面。前端 fetch/XHR 通常不会把 1xx 暴露为最终 status，多由浏览器底层消化。
| 码 | 名称 | 含义 / 前端何时遇到 |
|---|---|---|
| 100 | Continue | 客户端发了 Expect: 100-continue 探路，服务器允许继续发送请求体；上传大文件时底层使用 |
| 101 | Switching Protocols | 服务器同意切换协议——WebSocket 握手（Upgrade: websocket）成功时返回，前端建连必见 |
| 103 | Early Hints | 正式响应前先给 Link 首部，提示浏览器 preload/preconnect，提前加载关键资源 |
103 Early Hints —— 性能优化的"抢跑信号"
现代服务器在准备主响应（可能要查库、渲染）期间，可先回一个 103，携带 Link: </style.css>; rel=preload; as=style 之类首部。浏览器收到后立刻开始预加载样式、预连接 CDN，等真正的 200 到达时资源已在路上，显著改善首屏。它是面向性能的较新能力，前端通常无需手写，但理解它有助于读懂 Network 瀑布流里"正式响应前的提前加载"。
2xx 成功响应
请求已被服务器成功接收、理解并接受。注意"成功"不等于"有响应体"——204/205 就没有。
| 码 | 名称 | 含义 / 前端何时遇到 |
|---|---|---|
| 200 | OK | 最常见的成功；GET 拿到资源、POST/PUT 返回处理结果，响应体即数据 |
| 201 | Created | 资源已创建（常见于 POST 新增），通常配合 Location 指向新资源 URL |
| 202 | Accepted | 请求已受理但未完成——异步/批处理场景，结果稍后通过轮询或回调获取 |
| 204 | No Content | 成功但无响应体（DELETE 成功、表单提交无需回数据）；别去解析空 body |
| 206 | Partial Content | 范围请求的成功响应（断点续传、视频拖进度条），配合 Range 首部使用 |
200 不是唯一的成功码
REST 风格接口里：新增资源用 201、异步任务用 202、删除/无返回用 204 更语义化。前端处理时要注意：204 没有 body，对其调用 response.json() 会抛错；应先判断 status === 204 或 response.headers.get('Content-Length') === '0' 再决定是否解析。
3xx 重定向
请求需要进一步动作才能完成。3xx 的核心区分有两条轴：永久还是临时、是否保留原请求方法与请求体。（重定向目标地址由 Location 首部承载，详见 HTTP 首部精要。）
| 码 | 名称 | 含义 / 前端何时遇到 |
|---|---|---|
| 301 | Moved Permanently | 永久迁移，浏览器/搜索引擎会缓存并替换书签；历史上客户端常把后续方法改写成 GET |
| 302 | Found | 临时迁移，不应缓存；历史上也常被改写成 GET（语义比较"松"） |
| 303 | See Other | 让客户端改用 GET 去另一地址取资源；PRG 模式（POST 后重定向到结果页）的标准做法 |
| 304 | Not Modified | 协商缓存命中，用本地副本，响应无体；前端在 Network 见到它即缓存生效（语义见缓存页） |
| 307 | Temporary Redirect | 临时且严格保留原方法与请求体（POST 仍是 POST）——302 的"不改写"版本 |
| 308 | Permanent Redirect | 永久且严格保留原方法与请求体——301 的"不改写"版本 |
永久重定向辨析：301 vs 308
两者都表示资源永久搬家，浏览器和搜索引擎都会缓存并更新索引。区别只在请求方法：
308严格保留原方法和请求体——POST /old会变成POST /new。301在历史实践中常被客户端改写为GET（规范上不该如此，但浏览器为兼容老站点这么干了，已成既定行为）。
所以：站点换域名、HTTP→HTTPS 这类"只有 GET 页面"的迁移，301 足够且 SEO 友好；若 API 端点永久迁移且需保住 POST，必须用 308。
临时重定向辨析：302 vs 307 vs 303
三者都"临时"，差别在对请求方法的处理：
307 Temporary Redirect：严格保留方法与体，POST重定向后仍是POST——语义最明确的临时重定向。302 Found：语义较松，历史上常被改写成GET，行为不如 307 可预期。303 See Other：强制改成GET，且只取目标资源。这正是 PRG（Post / Redirect / Get） 模式的关键——表单POST成功后回303让浏览器GET结果页，避免用户刷新时重复提交。
经验法则：要"原样转发请求"用 307；要"提交后跳转到展示页"用 303；302 因行为含糊，新设计中尽量用 307/303 替代。
4xx 客户端错误
请求本身有问题，错在客户端——改正请求（补参数、补凭证、换方法）才有可能成功。前端调试接口时这一类最常打交道。
| 码 | 名称 | 含义 / 前端何时遇到 |
|---|---|---|
| 400 | Bad Request | 请求格式/参数有误，服务器拒绝理解；最常见的"通用客户端错误" |
| 401 | Unauthorized | 实为"未认证"——没登录或凭证无效；应带 WWW-Authenticate，前端常跳登录 |
| 403 | Forbidden | "已认证但无权"——身份已知但不允许访问该资源；登录了也照样拒绝 |
| 404 | Not Found | 资源不存在或 URL 不被识别；前端最熟悉的码 |
| 405 | Method Not Allowed | 方法不被该资源支持（如对只读端点发 DELETE）；响应常带 Allow 列出可用方法 |
| 408 | Request Timeout | 服务器等空闲连接超时主动关闭；偶发于慢网络 |
| 409 | Conflict | 请求与资源当前状态冲突（并发编辑、版本不一致、重复创建） |
| 410 | Gone | 资源永久删除且无转发地址；比 404 更明确"曾经有、现已彻底没了" |
| 413 | Content Too Large | 请求体超出服务器限制（上传文件过大）；前端应在上传前校验大小 |
| 415 | Unsupported Media Type | 请求体的媒体类型不被支持（如该接口只收 JSON 却发了 text/plain） |
| 422 | Unprocessable Content | 语法正确但语义校验失败（字段缺失、值非法）；REST API 表单校验常用此码 |
| 429 | Too Many Requests | 被限流——请求太频繁；配合 Retry-After 告知多久后可再试 |
401 vs 403 —— 前端最易混淆的一对
一句话区分：401 是"你是谁我不知道"，403 是"我知道你是谁，但不让你进"。
401 Unauthorized：名字有误导性，它真正的含义是"未认证（Unauthenticated）"。表示没有提供有效凭证（未登录、token 过期/无效）。规范要求响应带WWW-Authenticate首部。前端通常的处理：清除本地 token、跳转到登录页。403 Forbidden：表示"已认证但无授权（Unauthorized）"。身份已经确认，但该用户没有访问此资源的权限（如普通用户访问管理员接口）。前端处理：提示"无权限"，重新登录通常没用。
记忆口诀：401 去登录、403 别白费。 后端设计时也要分清——把"未登录"错回成 403、把"无权限"错回成 401，会让前端无法正确区分"该跳登录"还是"该提示无权"。
429 限流与 Retry-After
触发频控/限流时返回 429，服务器通常附带 Retry-After 首部（秒数或日期），告知客户端多久之后才能重试。前端正确做法是读取 Retry-After 并退避等待，而非立刻重发——否则只会加剧拥塞、甚至被封更久。配合指数退避（exponential backoff）是健壮请求层的标配。
5xx 服务端错误
请求看起来没问题，但服务器自己处理失败。前端一般无法靠改请求解决，多数是重试或等待服务恢复；线上排查时这一类是后端的信号。
| 码 | 名称 | 含义 / 前端何时遇到 |
|---|---|---|
| 500 | Internal Server Error | 通用服务器错误，没有更具体的码可用；后端代码抛异常的典型表现 |
| 501 | Not Implemented | 服务器不支持该请求方法；较少见 |
| 502 | Bad Gateway | 服务器作为网关/代理，从上游收到了无效响应（上游挂了或返回乱） |
| 503 | Service Unavailable | 服务暂不可用（维护、过载）；应配合 Retry-After 与友好错误页 |
| 504 | Gateway Timeout | 服务器作为网关/代理，等上游响应超时（上游太慢没及时回） |
502 vs 503 vs 504 —— 三个网关错误辨析
这三者在 Nginx/负载均衡后的微服务架构里很常见，按"问题出在哪"区分：
502 Bad Gateway：网关连上了上游，但上游返回了无效响应（崩溃、协议错乱、返回非法内容）。常见于后端进程挂掉、返回了网关无法解析的东西。503 Service Unavailable：服务本身明确表示"现在不可用"——正在维护、过载限流、或刻意下线。它是一种"主动的、有意的"不可用，应带Retry-After告知何时恢复，并配友好的维护页面。504 Gateway Timeout：网关在等上游响应时超时了——上游还活着但太慢，没在规定时间内返回。常见于后端处理过久、数据库慢查询。
速记：502 上游坏了、503 主动不可用、504 上游太慢。 前端遇到 503 可据 Retry-After 退避重试；遇到 502/504 通常是后端故障，重试或上报监控即可。
小结
状态码的第一位数字就是大方向：1xx 继续、2xx 成功、3xx 重定向、4xx 怪请求、5xx 怪服务器；真正的高频坑在 301/308、302/307/303 的"永久/临时 × 是否保留方法"四象限，以及 401（未认证）与 403（无权限）的混淆。掌握这些语义后，下一步去看承载这些状态的载体——HTTP 首部精要。