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（上游） → 回源拉取静态文件
因此，"上游"不是一个神秘新硬件，就是泛指"代理节点背后，真正处理请求的后端服务/容器/进程"。