HTML 缓存必须由服务器响应头 Cache-Control 控制，meta 标签无效；需配对启用 ETag 与 Last-Modified，静态资源路径须带内容哈希，Service Worker 需谨慎处理 HTML 缓存。
Cache-Control 响应头必须设，不能只靠 meta 标签
HTML 文件本身不执行缓存逻辑，浏览器是否缓存它，完全取决于服务器返回的 Cache-Control 响应头。用 <meta http-equiv="Cache-Control"> 是无效的——它在 HTML 解析阶段才生效，此时请求早已完成，浏览器早按响应头决定是否缓存了。
常见错误现象：index.html 总是 200（非 304），刷新后资源重新加载，首屏变慢；明明写了 max-age=3600 的 meta，Network 面板里仍显示 Cache-Control: no-cache。
- 配置位置：必须在 Web 服务器（Nginx/Apache）或 CDN（Cloudflare、阿里云 CDN）上设置响应头
- 推荐值：
Cache-Control: public, max-age=0, must-revalidate（HTML 通常不长期缓存，但需支持协商缓存） - 不要设
immutable—— HTML 内容常含动态时间戳或用户态信息，强制不可变会导致旧内容残留
ETag 和 Last-Modified 要配对启用，否则协商缓存失效
当 Cache-Control 设为 max-age=0, must-revalidate 或 no-cache 时，浏览器每次都会发条件请求，依赖 ETag 或 Last-Modified 判断是否命中。二者只开一个，容易因精度/生成策略不一致导致「本该 304 却返回 200」。
使用场景：静态 HTML 构建产物（如 Vue/React 打包后的 index.html）配合 CI/CD 自动注入哈希或构建时间戳。
立即学习“前端免费学习笔记（深入）”；
- Nginx 示例：
add_header ETag $md5_hash; add_header Last-Modified $date_gmt;（需配合md5指令或第三方模块生成文件内容哈希） - 避免用默认
inode+mtime+size生成 ETag —— 容器重启、多实例部署时 inode 不一致，ETag 失效 - 若用构建工具生成 HTML，更可靠的做法是把 content hash 注入
<meta name="build-hash">，再由后端读取并设为 ETag 值
HTML 中引用的 JS/CSS 路径要带内容哈希，不然缓存策略白配
即使 HTML 缓存策略再严谨，如果它引用的 main.js 路径不变，而文件内容变了，用户就可能拿到旧 HTML + 新 JS（或反之），造成运行时错误。这是最常被忽略的缓存断裂点。
性能影响：不带 hash 的资源无法长期缓存（只能设短 max-age），频繁回源增加延迟和带宽消耗。
- Webpack/Vite/Rollup 默认开启
contenthash，确保文件名随内容变化，例如main.a1b2c3d4.js - HTML 中必须用构建后的真实路径，不能硬写
src="main.js"；服务端渲染（SSR）场景下，需从构建产物 manifest.json 动态读取 - 注意：CSS 中的字体、图片 URL 也要走同样哈希机制，否则 CSS 缓存住，但内部引用的资源 404 或过期
Service Worker 会绕过 HTTP 缓存，调试时务必留意优先级
一旦注册了 Service Worker，所有匹配 scope 的请求默认由它接管。哪怕服务器返回了 Cache-Control: no-store，SW 仍可能从自己的 cache storage 返回旧 HTML —— 这不是配置错误，而是设计如此。
容易踩的坑：workbox.routing.registerRoute() 匹配 HTML 时用了 StaleWhileRevalidate 策略，但没处理 SW 更新逻辑，导致新版本 HTML 永远不生效。
- 上线新 SW 后，旧 SW 仍控制已打开页面；需调用
self.skipWaiting()+clients.claim()主动接管 - 调试建议：Chrome DevTools → Application → Service Workers → 勾选 “Update on reload”，并点击 “Unregister” 清理测试环境
- 更稳妥做法：对 HTML 请求禁用 SW 缓存，只缓存静态资源，让 HTML 始终走 HTTP 协商缓存（更可控、可观察）
