HTTP 缓存机制详解：从浏览器到服务器的优化之道
引言：为什么一个页面加载只需 200ms？
你有没有注意过，第一次访问某个网站时页面加载要花好几秒，但第二次打开几乎是瞬间完成的？这背后最大的功臣不是更快的网络，而是 HTTP 缓存。
HTTP 缓存是万维网最重要的性能优化手段之一。据 HTTP Archive 统计，一个典型的网页中有超过 60% 的资源（图片、CSS、JavaScript）可以被缓存——合理配置缓存可以将页面加载时间降低 80% 以上。更重要的是，它不仅能减少用户等待时间，还能降低服务器负载、节省带宽成本。
本文将深入浅出地介绍 HTTP 缓存的两种主要机制——强缓存和协商缓存——并演示如何通过 curl 命令亲手验证缓存行为。
一、HTTP 缓存的分类
HTTP 缓存按决策主体的不同，可以分为两大类：
- 强缓存（Strong Cache）：浏览器直接决定使用缓存，不向服务器发送请求。速度最快，完全不消耗网络资源。
- 协商缓存（Negotiation Cache）：浏览器向服务器发送请求「确认」缓存是否仍然有效，服务器返回 304 表示可用，浏览器继续使用缓存。仍有一次网络往返，但传输的数据量极小。
二、强缓存
2.1 Cache-Control
自 HTTP/1.1 开始，Cache-Control 就是控制缓存的首选方案。它通过一系列指令告诉浏览器（以及中间代理服务器）应该如何对待响应内容：
# 缓存 1 小时
Cache-Control: max-age=3600
# 从不缓存（敏感数据）
Cache-Control: no-store
# 每次都需要验证，但可以用缓存
Cache-Control: no-cache
# 缓存 1 年，但不允许中间代理缓存
Cache-Control: private, max-age=31536000
# 允许中间代理也缓存，适合公开资源
Cache-Control: public, max-age=86400用 curl 可以直观地看到真实网站的缓存配置：
$ curl -sI https://cdn.bootcdn.net/ajax/libs/vue/3.4.0/vue.global.prod.js | grep -i cache
cache-control: public, max-age=31536000
这个响应告诉浏览器：该文件公开可缓存，有效期1 年（31536000 秒）。在这一年内，浏览器永远不会再去请求这个文件——它会直接从本地缓存中读取，速度近乎零延迟。
2.2 Expires（HTTP/1.0 方式）
在 Cache-Control 普及之前，HTTP/1.0 使用 Expires 头来指定一个绝对过期时间：
Expires: Wed, 25 Jun 2027 10:00:00 GMT这个头的问题在于依赖服务器时间——如果服务器时钟不准，缓存行为就会出问题。因此现代网站通常同时使用两者，且 Cache-Control 的 max-age 优先级更高。
三、协商缓存
当强缓存过期后（或响应明确指定了 no-cache），浏览器需要向服务器验证缓存是否仍然有效。这个过程叫做「协商缓存」，通过两对标准头实现：
3.1 Last-Modified / If-Modified-Since
服务器在首次响应时返回资源的上次修改时间：
# 服务器第一次响应
HTTP/1.1 200 OK
Last-Modified: Tue, 20 Jun 2026 08:30:00 GMT
# 浏览器下次请求时带上这个时间
GET /style.css
If-Modified-Since: Tue, 20 Jun 2026 08:30:00 GMT
# 如果文件没有变化，服务器返回
HTTP/1.1 304 Not Modified
# 没有响应体，仅需几十个字节的头信息这种方式有一个缺陷：Last-Modified 精度只到秒级。如果文件在一秒内被多次修改，或者内容被修改后又改回原样（时间变了内容没变），服务器都会误判为需要重新传输。
3.2 ETag / If-None-Match（更精确）
为了解决上述问题，HTTP/1.1 引入了 ETag——一个由服务器根据文件内容计算出的唯一标识（通常是内容的哈希值）：
# 服务器第一次响应
HTTP/1.1 200 OK
ETag: "abc123def456"
# 浏览器下次请求时带上这个 ETag
GET /app.js
If-None-Match: "abc123def456"
# 如果内容没有变化，服务器返回
HTTP/1.1 304 Not Modified
# 如果内容变了，服务器正常返回 200 + 新资源ETag 比 Last-Modified 更可靠——只要文件内容没变，无论时间如何，ETag 都不会变。因此大多数现代框架和 CDN 都优先使用 ETag。
四、完整缓存流程
理解了上述机制后，浏览器加载一个资源时的完整决策流程如下：
- 检查本地缓存：是否有该资源的缓存副本？如果没有，直接发起网络请求。
- 判断强缓存是否有效：检查
max-age或Expires，如果未过期，直接从缓存读取（无网络请求）。 - 强缓存已过期：发起协商请求，携带
If-Modified-Since和/或If-None-Match。 - 服务器判断：
- 资源未变更 → 响应
304 Not Modified（无响应体） - 资源已变更 → 响应
200 OK+ 新资源
- 资源未变更 → 响应
整个过程可以用一句口诀来记忆：强缓存不过期就不问服务器；过期了问服务器，没变就 304。
五、动手验证：用 curl 观察缓存行为
理论说完了，我们来亲手验证。以流行的开源 CDN 为例：
# 查看一个静态资源的响应头
$ curl -sI https://cdn.jsdelivr.net/npm/vue@3/dist/vue.global.prod.js | head -20
# 输出节选：
# age: 1293883 ← 已缓存了约 15 天
# cache-control: public, max-age=31536000, immutable
# etag: "6d1a8f9e4b3c2d1a5f6e7d8c9b0a1f2e3d4c5b6a"
# last-modified: Sat, 30 Dec 2023 00:00:00 GMT
# 手动模拟协商缓存
$ curl -sI -H 'If-None-Match: "6d1a8f9e4b3c2d1a5f6e7d8c9b0a1f2e3d4c5b6a"' \
https://cdn.jsdelivr.net/npm/vue@3/dist/vue.global.prod.js | head -5
# 输出：
# HTTP/2 304
# ...（没有响应体，只有头信息）注意 age 这个头——它是 CDN 节点或代理服务器记录的资源「年龄」，表示这个缓存副本已经存在了多少秒。结合 max-age，你可以知道这个文件还有多久会过期。
六、最佳实践总结
在实际项目中，不同资源的缓存策略应该有所区分：
| 资源类型 | 推荐策略 | 说明 |
|---|---|---|
| HTML 页面 | no-cache | 内容经常更新，每次需要验证 |
| CSS/JS（带 hash） | public, max-age=31536000, immutable | 文件名指纹化，缓存一年 |
| 图片/字体 | public, max-age=2592000 | 一个月，可搭配 ETag |
| 用户数据 | private | 只允许浏览器缓存，代理不可见 |
| 支付/密码 | no-store | 永不缓存 |
其中 immutable 指令值得特别说明——它告诉浏览器「这个资源永远不会变，不要去协商验证」。搭配指纹化的文件名（如 app.a1b2c3.js），这是目前最激进而安全的缓存策略。
小结
HTTP 缓存并不神秘。它不过是服务器和浏览器之间的一套约定——通过几个关键的头字段（Cache-Control、ETag、Last-Modified），实现了让亿万用户每次访问网页都快上数秒的效果。
下次遇到网站加载慢的问题时，不妨打开 Chrome 开发者工具 → Network 面板，仔细观察每个资源的 Status 列：200 from disk cache、200 from memory cache、304……这些都是 HTTP 缓存在背后工作的痕迹。看懂它们，你就能真正掌控你网站的加载速度了。
评论区