304状态码是协商缓存生效的信号，表示资源未修改，浏览器复用本地缓存。它依赖客户端携带if-modified-since或if-none-match头，服务端比对后返回空响应体，节省带宽并提升性能。
304 状态码不是错误，而是协商缓存生效的明确信号。它出现在 fetch 发起请求后、浏览器已持有缓存副本、且服务端确认资源未变更的完整链路中。识别它，关键不是“看到 304”，而是理解它从哪来、依赖什么、又触发了什么。
一、触发前提：浏览器必须已有缓存副本
fetch 不会凭空发起协商请求。只有当目标资源此前被成功请求过，并满足以下任一条件时，后续 fetch 才可能走协商缓存：
- 上一次响应中包含 Cache-Control: no-cache（注意：不是不缓存，而是强制校验）
- 上一次响应中设置了 max-age=0 或已过期的 max-age
- 上一次响应中只有 Expires 且当前时间已超过该时间点
- 上一次响应中既无 Cache-Control 也无 Expires，但浏览器按启发式规则（如 Last-Modified 推算）判定需校验
二、请求发出时：自动携带协商头
当满足前提，fetch 发起新请求时，浏览器会自动在 Request Headers 中注入条件字段：
- If-Modified-Since：值来自上一次响应中的 Last-Modified 时间戳
- If-None-Match：值来自上一次响应中的 ETag 字符串（若存在）
这两个头同时存在时，服务端通常优先比对 ETag（更精确），Last-Modified 是兜底方案。你可以在 Chrome DevTools 的 Network 面板中展开该请求 → Headers → Request Headers 下直接看到它们。
三、服务端判断逻辑：比对 + 决策
服务器收到带 If-xxx 头的请求后，执行两步操作：
- 读取当前资源的真实 Last-Modified 时间 和 / 或 计算当前内容的 ETag（例如基于文件内容哈希）
- 将它与请求头中的 If-Modified-Since 或 If-None-Match 值严格比对
只要任一匹配成立（ETag 相等 或 Last-Modified 时间一致且资源未改动），服务端就不返回响应体，仅返回空响应体 + 状态码 304 + 原始响应头中的 Cache-Control、ETag、Last-Modified 等（可选刷新）。
四、客户端接收后：复用本地缓存
fetch 收到 304 响应后，不会解析响应体（因为没有），而是直接从本地磁盘或内存缓存中取出之前保存的完整资源副本，作为本次 fetch 的 response.body 和对应 MIME 类型使用。开发者工具中你会看到：
- Status Code 显示为 304 Not Modified
- Size 列显示极小（如 “132 B”），远小于原始资源大小
- Response 标签页为空或只显示响应头，无 HTML/CSS/JS 内容
- Timing 标签页中 “Waiting (TTFB)” 很短，“Content Download” 几乎为 0ms
此时 JavaScript 中通过 response.text() 或 response.json() 获取的数据，实际来自缓存，而非网络传输。
