html缓存由服务端cache-control响应头唯一控制，meta标签无效；index.html不可设immutable或长max-age，否则导致资源引用错乱；验证需通过network面板观察from memory/disk cache或304状态。
HTML 本身不发起“请求缓存”，真正决定是否复用响应的，是浏览器对 index.html（或任何 HTML 文件）的 HTTP 缓存策略。你无法靠 JS 或 meta 标签可靠控制它——必须由服务端响应头主导。
Cache-Control 是 HTML 缓存的唯一可靠开关
浏览器对 HTML 的缓存行为几乎完全取决于服务端返回的 Cache-Control 响应头。其他方式（如 <meta http-equiv="cache-control">）在现代浏览器中被忽略，Chrome、Firefox、Safari 均不执行该 meta 指令。
-
Cache-Control: no-cache：最常用。允许缓存 HTML，但每次使用前必须向服务器发条件请求（带If-None-Match或If-Modified-Since），服务端返回304 Not Modified才复用本地副本 -
Cache-Control: max-age=300：5 分钟内直接读缓存，不发任何请求；超时后走协商流程 -
Cache-Control: must-revalidate：即使用户点了刷新，也强制校验，防止 stale 内容被无条件展示 - 避免用
Expires单独控制 HTML —— 它依赖客户端时间，偏差会导致缓存提前失效或顽固不更新
为什么 index.html 绝不能设成 immutable 或 long max-age
HTML 是应用入口，内容常变（路由、版本号、动态脚本引用）。若设 Cache-Control: public, max-age=31536000, immutable，用户刷新页面也不会触发新请求，旧 HTML 会持续加载过期的 main.a1b2c3.js 或错误的 API 地址。
- Service Worker 场景下，
index.html必须设为no-cache或短max-age，否则新 SW 版本无法被发现和激活 - CDN 缓存 HTML 时，若没配好缓存键（比如忽略 query string 或 header 差异），可能把 A 用户的登录态 HTML 返回给 B 用户
- 构建工具（Vite、Webpack）生成的
index.html通常含哈希化资源引用（如src="assets/index.7f8a.js"），这要求 HTML 自身不可长期缓存——否则新构建上线后，用户仍加载旧 HTML，引用的仍是旧 hash 资源
验证 HTML 是否真的被缓存了
别猜，直接看 Network 面板。打开 DevTools → Network → 刷新页面 → 找到 index.html 请求行：
- Size 列显示
from memory cache或from disk cache→ 确实命中强缓存 - Size 列显示字节数（如
2.4 KB）且 Status 是304→ 走协商缓存，服务端确认未变 - Status 是
200且 Size 是具体数值 → 完全重新下载，缓存未生效（检查响应头是否被覆盖、CDN 是否透传） - 按
Ctrl+Shift+R（Windows）或Cmd+Shift+R（Mac）是强制跳过所有缓存的硬刷新，此时永远看不到from disk cache，别用它判断日常缓存行为
常见破环 HTML 缓存的隐形操作
很多看似无关的动作，实际会绕过或污染缓存逻辑：
- 本地开发用
file://协议打开 HTML：无 HTTP 头，浏览器禁用缓存，Cache-Control完全无效 - Nginx/Apache 配置中，对
.html文件误加了add_header Cache-Control "no-store"，导致所有 HTML 被禁止缓存 - 后端框架（如 Express、PHP）在响应前手动调用了
res.set('Cache-Control', '...')，但被后续中间件覆盖或拼写错误（如写成cache-control小写） - 代理层（如 Cloudflare）设置了 Page Rule 强制缓存 HTML，而源站响应头却是
no-cache，此时以代理规则为准，且可能不透传 ETag
缓存不是开个开关就完事的事。HTML 的缓存粒度极粗，一旦出错，整个页面逻辑就错位。盯住 Cache-Control 响应头、验证 Network 行为、避开本地 file 协议和代理干扰——这三件事做扎实，比堆十个 meta 标签管用得多。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
