缓存可以减少重复下载，也可能让访客一直看到旧页面。设计博客的缓存策略时，先区分会更新的页面与内容不变的资源，再决定缓存期限。

三类文件，三种处理思路

资源 更新特点 策略方向
HTML、搜索索引 发布文章时会变化 使用前重新验证，或短期缓存
带内容指纹的 CSS、JS、图片 内容改变时 URL 也改变 可以长期缓存
固定文件名的图片与脚本 URL 不变但内容会替换 避免未经验证的长期缓存

例如 app.8c21ab.js 的文件名包含内容指纹，而 site.js 只是固定名称。不能因为两者都是 JavaScript，就套用相同的长缓存规则。

no-cache 不等于不保存

Cache-Control: no-cache
ETag: "example-version"

no-cache 允许存储响应，但在再次使用前需要验证。浏览器可以带上 If-None-Match；内容没有变化时，服务器返回 304 Not Modified，避免重复传输完整正文。

no-store 则用于不应存储的响应。这两个指令的作用不同，不能互换。

immutable 需要稳定的资源地址

对真正使用内容指纹、并且以后不覆盖该 URL 的资源，可以考虑：

Cache-Control: public, max-age=31536000, immutable

一年缓存不是通用的“性能开关”。如果固定文件名脚本使用这个响应头，修改后访客可能继续运行旧代码。当前项目的 custom/site.js 等文件没有内容指纹，不应直接套用这条策略。

离线缓存是另外一层

原参考站介绍过 hexo-offline。它通过 Service Worker 管理缓存；这与浏览器 HTTP 缓存不是同一个机制。

引入离线能力前，要明确哪些页面允许离线读取、怎样清理旧缓存，以及新版本什么时候接管页面。不要默认预缓存整站视频和所有画廊图片。

本文只整理策略，不向当前网站安装离线插件，避免让本地调试混入额外的旧版本缓存。

验证是否真的生效

在浏览器开发者工具的 Network 面板检查 Cache-Control、状态码和传输量。分别测试首次访问、普通刷新和资源更新后访问；关闭缓存的调试结果不能代表日常访问效果。

如果部署经过 CDN，还要检查 CDN 的缓存规则及失效机制。页面、边缘节点、浏览器和 Service Worker 可能分别保留不同版本。

参考资料

选题参考：Sakura Yumine：使用 hexo-offline 优化博客访问速度。本文改写为 HTTP 缓存策略笔记。

技术依据：MDN：HTTP caching。