报文·首部·状态码与 HTTP 缓存
前节侧重 报文结构与状态码，后节侧重 缓存策略。
第一部分：报文、首部与状态码
HTTP 报文由 起始行、首部字段、空行、可选正文 组成；请求与响应各有常用首部。
请求侧（常见）
| 首部 | 作用 |
|---|---|
Host | 虚拟主机路由必带 |
Accept / Accept-Encoding / Accept-Language | 可接受的类型、压缩、语言 |
Content-Type | 请求体 MIME（如 application/json） |
Authorization | 凭证（Bearer Token 等） |
Cookie | 浏览器自动携带的同源 Cookie |
If-None-Match / If-Modified-Since | 协商缓存验证 |
Origin | CORS 预检与跨域请求标识来源 |
响应侧（常见）
| 首部 | 作用 |
|---|---|
Content-Type | 响应体类型 |
Cache-Control / Expires | 强缓存 |
ETag / Last-Modified | 协商缓存标签 |
Set-Cookie | 服务端种下 Cookie |
Location | 重定向目标 |
状态码族（速查）
| 区间 | 含义 | 常见 |
|---|---|---|
| 1xx | 信息 | 100 Continue，101 Switching Protocols |
| 2xx | 成功 | 200 OK，201 Created，204 No Content |
| 3xx | 重定向 | 301 永久，302/307/308 临时，304 Not Modified（缓存验证） |
| 4xx | 客户端错误 | 400 参数错，401 未认证，403 无权限，404 不存在，429 限流 |
| 5xx | 服务端错误 | 500 内部错误，502 网关坏，503 不可用，504 网关超时 |
304：响应无正文，浏览器使用本地缓存副本（配合 ETag/Last-Modified）。
小结
定位接口问题：先看状态码族 → 再看响应头 Content-Type / 缓存相关 → Network 里对照请求方法是否与幂等语义一致。
第二部分：HTTP 缓存
目的：减少重复传输、降低服务端压力、加快加载。分为 强缓存 与 协商缓存，浏览器通常 先尝试强缓存，失效再协商。
强缓存（不发请求或极少）
由响应头告知浏览器在有效期内 直接使用本地副本。
| 首部 | 说明 |
|---|---|
Cache-Control | HTTP/1.1 主用，如 max-age=31536000、public/private |
Expires | HTTP/1.0 绝对过期时间，易被 Cache-Control 覆盖 |
常用指令：
max-age：秒级生存时间。no-cache：并非不缓存，而是 使用前必须与服务器验证（走协商）。no-store：完全不存，适合敏感数据。
协商缓存（发请求，可能 304）
浏览器带上缓存校验字段，服务器判断资源是否变化。
| 响应给出 | 下次请求携带 | 说明 |
|---|---|---|
Last-Modified | If-Modified-Since | 秒级精度，内容未变也可能变时间戳 |
ETag | If-None-Match | 实体标签，通常更精准 |
未变更则 304 Not Modified，正文从磁盘读。
SPA 常见策略（提要）
- 带 hash 的静态资源：文件名变化即新 URL，可配 长
max-age。 - 入口 HTML：多用
no-cache或短缓存，确保尽快拿到新引用。
与「JS 里看到的缓存」
浏览器 HTTP 缓存与 Memory Cache / Disk Cache 的表现可在 DevTools Network 的 Size 列观察（from disk cache 等）。与 Service Worker 缓存 不同 layer，勿混淆。
小结
记清：no-cache vs no-store；强缓存省请求，协商缓存靠 ETag/304；接口动态数据慎用强缓存。