HTTP缓存机制详解：强缓存与协商缓存

引言

在Web性能优化中，HTTP缓存是最有效的手段之一。合理使用缓存可以显著减少网络传输、降低服务器压力、提升页面加载速度。但很多开发者对缓存机制的细节一知半解，导致线上出现“用户看到旧页面”或“缓存完全失效”等问题。

HTTP缓存主要分为两类：强缓存（本地缓存）和协商缓存（条件请求）。本文将从原理、响应头字段、行为对比三个方面帮你彻底理清。

一、强缓存：直接使用本地副本

强缓存是指浏览器在缓存有效期内不会向服务器发送任何请求，而是直接使用本地缓存的资源。命中强缓存时，开发者工具的 Network 面板会显示 from disk cache 或 from memory cache，状态码为 200 (from cache)。

控制强缓存的响应头有两个：

• Expires（HTTP/1.0）：一个绝对时间戳，例如 Expires: Wed, 21 Oct 2025 07:28:00 GMT。缺点是依赖客户端本地时间，如果用户改系统时间可能出错。
• Cache-Control（HTTP/1.1，优先级更高）：使用相对时间，如 Cache-Control: max-age=3600 表示资源在 1 小时内有效。常用指令：
  • max-age=<秒>：最大缓存时间
  • no-cache：不是不缓存，而是跳过强缓存，强制走协商缓存（容易误解）
  • no-store：完全不缓存，每次从服务器下载
  • public / private：是否允许代理服务器缓存

示例：

HTTP/1.1 200 OK
Cache-Control: max-age=86400

这表示该资源在 24 小时内浏览器直接使用本地缓存，不发出请求。

二、协商缓存：向服务器确认是否可用

当强缓存失效（或未命中）时，浏览器会携带缓存标识向服务器发起请求，由服务器判断缓存是否仍然有效。如果有效，服务器返回 304 Not Modified，浏览器继续使用本地副本；如果无效，返回 200 和新资源。

协商缓存有两对配合使用的头部字段：

1. Last-Modified / If-Modified-Since

• 服务器响应时返回 Last-Modified: Tue, 01 Oct 2025 12:00:00 GMT
• 浏览器下次请求时携带 If-Modified-Since: <上次的 Last-Modified 值>
• 服务器比较资源最后修改时间，若未变化则返回 304

缺点：时间精度只到秒级，且文件内容变化但修改时间未变时会导致误判。

2. ETag / If-None-Match

• 服务器响应时返回 ETag: "abc123"（资源唯一标识，通常由文件哈希或版本号生成）
• 浏览器下次请求时携带 If-None-Match: "abc123"
• 服务器比较 ETag，一致则返回 304

ETag 优先级高于 Last-Modified，因为它是内容级别的精确比较。但生成 ETag 会增加服务器开销，需权衡使用。

示例（首次请求）：

HTTP/1.1 200 OK
ETag: "5f8a3b2c"
Last-Modified: Tue, 01 Oct 2025 12:00:00 GMT

后续请求：

GET /style.css HTTP/1.1
If-None-Match: "5f8a3b2c"
If-Modified-Since: Tue, 01 Oct 2025 12:00:00 GMT

服务器判断无变化：

HTTP/1.1 304 Not Modified

三、对比与最佳实践

推荐配置策略：

• 对带哈希指纹的静态资源（如 app.a1b2c3.js），设置 Cache-Control: max-age=31536000（一年），因为文件名变化即刷新缓存。
• 对 HTML 文件，设置 Cache-Control: no-cache 配合 ETag，确保总能获取最新入口。
• 避免同时使用 no-store 和强缓存字段，语义冲突。

总结

强缓存让浏览器“自信”地直接使用本地副本，性能最高但更新不灵活；协商缓存通过一次轻量的 304 请求保证内容最新，适合需要动态校验的场景。理解两者的协作关系：先走强缓存，失效后再走协商缓存，是构建高性能 Web 服务的基础。

掌握这些机制后，你就能根据资源类型精准设置缓存策略，告别“用户看不到新版本”和“缓存命中率低”的烦恼。