HTML 缓存只能由服务端 HTTP 响应头（如 Cache-Control、ETag）控制，meta 标签完全无效；HTML 应用 no-cache + ETag 协商缓存，而 JS/CSS 等带 hash 的静态资源可设 long-term cache。
HTML 本身没有“缓存机制”可利用——meta 标签里的 http-equiv="Cache-Control" 或 Expires 在 Chrome、Firefox、Safari 中全被忽略，压根不生效。真正起作用的只有 HTTP 响应头，必须由服务端（Nginx / Apache / Node.js 等）在返回 HTML 时设置 Cache-Control 和 ETag。
为什么不能靠 <meta http-equiv> 控制 HTML 缓存
浏览器只认响应头，不解析 HTML 内容来决定是否缓存。哪怕你写：
<meta http-equiv="Cache-Control" content="max-age=3600">
它也不会影响缓存行为。原因很实在：
-
Expires是 HTTP/1.0 遗留字段，依赖客户端和服务端时钟严格同步；现实里差几秒就导致缓存提前失效或误命 -
meta标签只在页面渲染阶段起作用，而缓存决策发生在网络层（HTTP 协议解析阶段），此时 HTML 还没开始下载 - CDN、反向代理、浏览器预加载器一律跳过
meta，只看响应头
Cache-Control 对 HTML 的正确取值
HTML 页面不能像 JS/CSS 那样设成长期强缓存，否则用户改了内容却刷不出新版本。推荐策略是：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- 用
Cache-Control: no-cache：不是禁止缓存，而是强制走协商流程（带If-None-Match或If-Modified-Since请求头） - 配合
ETag（而非Last-Modified）：因为构建工具（如 Vite）可能重写文件 mtime，导致秒级时间戳错乱；ETag基于内容哈希，更可靠 - 避免
max-age过长：设成max-age=0或干脆不设，把控制权交给协商缓存
Nginx 默认开启 ETag；Apache 要确认没禁用 FileETag 指令。
静态资源（JS/CSS/图片）和 HTML 必须分开配置
混用同一套缓存策略会出问题：
- JS/CSS 文件名带 content hash（如
main.a1b2c3.js）→ 可放心用Cache-Control: public, max-age=31536000, immutable - HTML 文件名不变（如
index.html）→ 必须用no-cache+ETag，否则用户永远看不到更新 - 如果 HTML 里内联了 JS/CSS（
<script>或<style>），这些内容随 HTML 一起变，也得走协商缓存，不能单独强缓存
最常被忽略的一点：HTML 缓存失效不是“清不清缓存”的问题，而是“有没有让浏览器知道它该重新验证”。只要服务端没发正确的 ETag，或者前端构建后没触发 HTML 内容变更（比如只改了 JS 文件但 HTML 里引用路径没变），协商请求就会一直返回 304，用户始终看到旧页面。
