HTML文件的强缓存只能由服务器响应头（Cache-Control/Expires）控制，meta标签完全被现代浏览器忽略；验证需通过DevTools查看Status是否为“200 from disk/memory cache”及Response Headers中Cache-Control字段。
HTML 文件本身不能配置强缓存机制——所有生效的缓存控制都来自服务器返回的 HTTP 响应头，Cache-Control 和 Expires 才是真正起作用的指令；写在 里的内容现代浏览器（Chrome/Firefox/Edge/Safari）完全忽略。
为什么直接在 HTML 里写 meta 标签没用
这个标签是早期为兼容 IE 设计的模拟机制，实际不参与 HTTP 缓存决策流程：
– 浏览器不会用它生成 If-None-Match 或 If-Modified-Since 请求头
– 不触发 304 协商流程，也不影响强缓存是否命中
– DevTools Network 面板里永远看不到它出现在 Response Headers 中
– 本地用 file:// 协议打开时看似“生效”，其实连 HTTP 协议都没走，纯属误导
强缓存必须靠服务端响应头配置
对 HTML 文件启用强缓存（比如 max-age=3600）极其危险，但如果你确认页面是纯静态、无用户态、无时间戳、无 CSRF token，且构建产物路径已带内容哈希，可按以下方式配置：
- Nginx：在匹配
index.html的location块中加add_header Cache-Control "public, max-age=3600"; - Express：路由中调用
res.set("Cache-Control", "public, max-age=3600") - Vercel：在
_headers文件中写/index.html→cache-control: public, max-age=3600 - 注意：CDN（如 Cloudflare）必须同步该头，否则边缘节点可能缓存旧版本，而源站已更新
怎么验证强缓存是否真的生效
别信地址栏回车或 F5——它们可能走协商缓存或内存缓存。正确验证方式：
- 打开 DevTools → Network → 刷新页面 → 找到
index.html请求 - 看 Status 列：如果是
200 from disk cache或200 from memory cache，说明强缓存命中 - 看 Response Headers：必须包含
Cache-Control且值含max-age=...，不含no-cache、no-store、must-revalidate - 如果状态码是
304 Not Modified，那是协商缓存，不是强缓存
真正容易被忽略的是：HTML 强缓存一旦生效，就锁死了整个页面结构和资源引用路径。哪怕你更新了 main.a1b2c3.js，只要 HTML 还在强缓存期内，它仍会加载旧的 main.xyz789.js——除非你同时更新 HTML 内容并让其失效。所以绝大多数场景下，index.html 应该用 no-cache 或 max-age=0, must-revalidate，把强缓存留给带哈希的 JS/CSS/图片。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
