如何识别 304 状态码与 fetch 缓存机制

304状态码并非错误，而是浏览器与服务器协同完成高效缓存复用的关键信号——当fetch请求触发协商缓存时，浏览器自动携带If-None-Match或If-Modified-Since头发起校验，服务端比对ETag或最后修改时间后确认资源未变，便返回无响应体的304响应；此时fetch会无缝复用本地缓存内容，显著减少带宽消耗与加载延迟，真正实现“不下载、只验证、秒返回”的性能优化闭环。

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() 获取的数据，实际来自缓存，而非网络传输。

好了，本文到此结束，带大家了解了《如何识别 304 状态码与 fetch 缓存机制》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！