HTTP 缓存：分清「直接复用」和「问一声再用」

缓存的目标是复用已经获取的响应，减少传输与等待。理解它，可以先分开两个问题：响应能保存吗？保存之后，什么时候可以复用？

新鲜时，直接使用

服务器可以通过响应头声明缓存策略：

Cache-Control: public, max-age=3600

max-age 指定响应在缓存中的新鲜期限，单位是秒。在满足相关条件时，新鲜响应可以直接复用，而不必每次都访问源站。共享缓存与浏览器私有缓存，还可能采用不同的规则。

不要把它理解为「从每次打开页面开始再计时一小时」。缓存还会结合响应时间和 Age 等信息计算当前年龄。

需要验证时，带上版本标记

服务器可以附带一个资源版本标识：

ETag: "notes-v3"

后续验证请求带上 If-None-Match。如果资源仍匹配，服务器可以返回 304 Not Modified，让缓存复用已有内容，省去再次传输完整响应体。

缓存有副本 → 仍新鲜？ ── 是 → 直接复用
                │
                否
                ↓
             向服务器验证
                ├─ 未修改 → 304 → 复用已有内容
                └─ 已修改 → 200 → 获取新内容

no-cache 不等于 no-store

no-cache 允许保存，但在复用前需要成功验证。no-store 要求缓存不要存储这个请求或响应的内容。对已有缓存的清除以及用户历史等问题，还需要另行考虑。

private 表示响应只应由私有缓存保存，不能被共享缓存存储。涉及个人数据时，应结合认证方式与完整响应策略设计，不能只随手加一个缓存头。

静态资源的实用策略

首页 HTML 可以使用较短的新鲜期，或者在复用前验证；带内容哈希的 CSS 与 JavaScript 文件可以配置更长的缓存时间，因为内容改变时 URL 也会改变。

如果资源 URL 固定，却设置了很长的缓存期，发布新版本后，访客可能仍然使用旧资源。缓存策略与文件命名需要一起设计。

# 先观察服务器真实返回的头
curl -I https://neoapp.top/assets/site.css

调试时也要检查开发者工具是否勾选了 Disable cache。一个开关就可能改变你以为自己正在观察的行为。

继续阅读

• MDN：HTTP 缓存