Informational（信息性）——“请稍等，我还没完呢”
只有协议交互用，浏览器层面基本看不到。
1. 100 Continue
场景：客户端准备在 POST/PUT 里扔几百 KB 甚至几十 MB 的表单或文件，怕一发过去就被拒，浪费流量。
流程：
① 客户端先发一个带 Expect: 100-continue 的请求头，只传请求头，不传正文。
② 服务器若愿意收，就回 100 Continue（不带头体）。
③ 客户端收到 100，才继续把大块数据发完；如果服务器直接回 4xx/5xx，客户端就中止，省掉上传流量。
日常现象：浏览器里看不到 100，它发生在后台；用 curl、Postman、OSS/MinIO 上传大文件时最常见。
注意：部分老服务器（lighttpd 1.4、早期 Resin）不认这个头，会扔 417 Expectation Failed，此时客户端要关掉 Expect。
2. 101 Switching Protocols（ws 升级）
场景：HTTP 只负责握个手，真正想“打电话”得换成 WebSocket、HTTP/2、QUIC 等“长连接”协议。
流程：
① 客户端发 Upgrade: websocket + Connection: Upgrade 等头。
② 服务器同意，回 101，并在响应头里带上同样的 Upgrade: websocket。
③ 空行结束后，双方立即改用 WebSocket 帧格式通信，后面再没 HTTP 什么事了。
日常现象：浏览器控制台 Network 标签里，第一条请求状态码是 101，后面全是 ws 帧；聊天室、在线游戏、股票推送都用它。
注意：如果代理/防火墙把 Upgrade 头剥掉，101 就不会出现，WebSocket 会直接连不上。
Success（成功）——“一切 OK，你要的东西在包里”
200 OK 常规成功
201 Created 已新建（POST 后常用）
场景：POST 上传资源、PUT 新建文件、调用 RESTful 接口“新增用户/订单/文章”成功。
特点：服务器必须在响应头里给 Location: 新资源的完整 URL，告诉客户端“东西我帮你存好了，以后就来这儿取”。
日常现象：调后端 API 返回 201 + Location，前端一般弹“新建成功”，并跳转到刚创建的详情页
204 No Content 成功但无返回体（DELETE/OPTIONS 常用）
场景：服务器成功执行了删除、保存、设置操作，但没必要再回任何数据。
特点：响应头可以带更新后的元信息（ETag、Last-Modified），但实体体必须为空。
日常现象：
前端发 DELETE /api/user/123 后收到 204，页面列表直接把那条记录移除即可，无需再解析响应体。
表单保存后服务器回 204，页面不刷新，用户继续留在当前视图
Redirection（重定向）——“东西不在我这，去别处拿”
301 Moved Permanently
永久搬家。浏览器收到后会缓存这个重定向，下次访问原 URI 直接跳新地址，SEO 权重也会转移。
302 Found（原叫 Moved Temporarily）
临时搬家。下次访问还会先问原地址，适合登录跳转、推广活码等场景。
303 See Other
强制客户端用 GET 方法去 Location 拿结果，常用于 POST 表单后“转回列表页”，防止刷新时重复提交。
304 Not Modified
资源内容没动，你本地缓存还能继续用。服务器只回响应头，不回包体，省流量。触发条件是客户端带的 If-Modified-Since/If-None-Match 与服务端比对一致
码 | 英文短语 | 一句话记忆 |
301 | Moved Permanently | 永久搬家，搜索引擎把权重带走 |
302 | Found（原 Moved Temporarily） | 临时搬家，下次还来原地址问 |
303 | See Other | 用 GET 去另一个地址拿（POST-redirect-GET 模式） |
304 | Not Modified | 你缓存还有效，继续用，省流量 |
307 | Temporary Redirect | 302 的“严格版”，禁止把 POST 变成 GET |
308 | Permanent Redirect | 301 的“严格版”，同样禁止改方法 |
Client Error（客户端错）——“你自己搞错了”
码 | 一句话记忆 |
400 Bad Request | 语法/参数不对 |
401 Unauthorized | 没登录，先交凭证 |
403 Forbidden | 登录了也没权限 |
404 Not Found | 地址写错或资源被删 |
405 Method Not Allowed | 该接口不支持你用的 GET/POST 等 |
408 Request Timeout | 你发得太慢，服务器不等了 |
429 Too Many Requests | 调用太频繁，被限流 |
Server Error（服务端错）——“我这边挂了”
500 Internal Server Error
万能“背锅码”：业务代码抛异常、配置错误、空指针、数据库连不上……服务器只能说“我内部错了”，具体原因得看日志。
502 Bad Gateway
网关/反向代理（Nginx、CDN、ELB）自己工作正常，但从上游（后端、PHP-FPM、Tomcat）拿到无效或过早断开的响应，于是报 502。
503 Service Unavailable
服务器暂时不能处理，可能在维护、重启、限流、过载。响应头里通常带 Retry-After: 秒数，告诉客户端多久后再试。
504 Gateway Timeout
代理在限定时间内没等到上游回包，比 502 更“拖”：连得上，但上游慢到超时。
码 | 一句话记忆 |
500 Internal Server Error | 通用“锅”码，后端代码崩了 |
502 Bad Gateway | 代理/网关从上游拿到无效响应 |
503 Service Unavailable | 服务器在维护或超载，稍后再试 |
504 Gateway Timeout | 代理等上游响应超时 |
上游的介绍
在技术栈里，“上游”（upstream）就是 Nginx、CDN、负载均衡器、API 网关这类“前台”背后，真正生成内容的那一组服务器。常见组合举例：
LNMP 架构
用户 → Nginx（前台） → php-fpm 进程池（上游） → 返回 HTML
Java 传统架构
用户 → Nginx → Tomcat/Jetty（上游） → 返回 JSON/HTML
微服务网关
用户 → Kong/Gateway → 订单服务 Pod、用户服务 Pod（上游） → 返回业务数据
CDN 场景
用户 → Cloudflare CDN → 源站 ECS（上游） → 回源拉取静态文件
因此，“上游”不是一个神秘新硬件，就是泛指“代理节点背后，真正处理请求的后端服务/容器/进程”。
)
