HTML本身不提供可编程缓存机制，所谓“HTML缓存”实为浏览器对HTML文件应用HTTP缓存策略的结果；真正提升效率的是配合Cache-Control、文件哈希命名、避免HTML长缓存。
直接说结论：HTML 本身不提供可编程的缓存机制，所谓“HTML缓存”其实是浏览器对 HTML 文件自身应用 HTTP 缓存策略的结果；真正能提升资源访问效率的，是配合 Cache-Control、文件哈希命名、以及避免对 HTML 文件做长缓存这三件事。
为什么不能给 HTML 文件配 long cache
HTML 是前端资源的入口和调度中心。一旦它被强缓存（比如 Cache-Control: max-age=31536000），而内部引用的 app.js 或 style.css 已更新，用户就永远拿不到新版本——因为浏览器根本不会重新请求 HTML，自然也看不到里面新的哈希文件名。
- 典型现象：发版后用户刷新页面，JS 报错、样式丢失、按钮点击无反应
- 根本原因：HTML 缓存时间太长，且没用哈希，导致引用了旧资源路径
- 正确做法：HTML 文件应设为
no-cache或极短max-age=60，强制每次请求都走协商缓存（带If-None-Match）
静态资源必须用内容哈希命名
JS/CSS/图片这类静态资源可以且应该长期缓存，但前提是文件名能反映内容变化。否则浏览器认不出“新文件”和“旧文件”的区别，只会复用旧缓存。
- 错误写法：
<script src="app.js"></script>—— 每次更新都覆盖同名文件，浏览器无法感知变更 - 正确写法：
<script src="app.a1b2c3d4.js"></script>—— 构建工具（如 Webpack/Vite）自动生成基于内容的哈希 - 配套响应头必须是：
Cache-Control: public, max-age=31536000, immutable（immutable告诉浏览器：这个 URL 永远不会变内容，不用再发 If-None-Match）
协商缓存不是万能的，ETag 和 Last-Modified 要慎用
当 HTML 或 API 接口需要短缓存时，常依赖 Last-Modified 或 ETag 触发 304。但这两者在实际部署中容易出问题：
立即学习“前端免费学习笔记（深入）”；
-
Last-Modified精度只有秒级，同一秒内多次构建可能生成相同时间戳，导致缓存误判 -
ETag默认由 Nginx 基于文件 mtime + size 生成，如果构建产物被 rsync 同步或容器重建，mtime 变更会导致 ETag 失效，引发大量 200 响应 - 更稳的选择：静态资源全用哈希 +
immutable；动态接口统一用Cache-Control: no-cache，由前端逻辑控制是否重拉
最易被忽略的一点：CDN 会缓存你没意识到的响应头。哪怕你本地 Nginx 配了 Cache-Control: no-cache，如果 CDN 节点之前缓存过 HTML 且没配置 bypass 规则，它仍可能返回旧 HTML。上线前务必确认 CDN 的缓存 key 是否包含 Cookie 或 Authorization，并检查其缓存层级是否覆盖了 HTML 路径。
