HTML必须禁用长期强缓存，因其作为页面入口，若被缓存将导致用户加载旧版本并请求404的JS资源或复用错误JS；应设Cache-Control: no-cache并配合ETag/Last-Modified实现协商缓存，同时在CDN、Nginx、Webpack、Service Worker各层协同控制。
生产环境的HTML缓存不能简单设为 Cache-Control: public, max-age=3600 就完事——它会直接导致用户看不到新版本，且无法被CDN或Service Worker正确接管。
为什么HTML文件必须禁用长期强缓存
HTML是整个页面的入口，它的内容决定了后续加载哪些JS/CSS资源。如果HTML被浏览器或CDN缓存了1小时，而你已发布带 [contenthash] 的新JS文件，用户仍会加载旧HTML，从而请求旧哈希名的JS（404）或错误复用缓存中的旧JS（功能异常）。
- 所有主流CDN（Cloudflare、阿里云DCDN、AWS CloudFront）默认对
.html后缀启用缓存，必须显式覆盖 - Service Worker 的
fetch事件若未拦截HTML请求，也会走浏览器默认缓存逻辑 -
index.html在单页应用中常被 Nginx 配置为try_files $uri /index.html，若该文件被强缓存，路由变化后白屏风险极高
正确的HTTP响应头配置组合
核心原则：HTML不走强缓存，但要支持协商缓存，避免每次都是200响应体传输。
- 必须设置
Cache-Control: no-cache—— 注意这不是“不缓存”，而是强制浏览器在使用前向服务端验证 - 必须提供
ETag或Last-Modified，否则no-cache会退化为每次都发完整请求（无意义） - 避免使用
Expires，它在 HTTP/1.0 中优先级最低，且易与服务器时间不同步造成误判 - 若用 Nginx，配置类似：
add_header Cache-Control "no-cache"; add_header ETag $upstream_http_etag;（需后端实际输出ETag）
构建工具层的协同控制（以 html-webpack-plugin 为例）
仅靠服务端头不够，Webpack 构建时也要切断HTML缓存链路：
立即学习“前端免费学习笔记（深入）”；
- 关闭
html-webpack-plugin的cache选项（cache: false），防止开发时模板变更未触发重编译，导致本地测试与线上不一致 -
minify设为false或明确对象（勿用'auto'），因为压缩逻辑变更可能让两次生成的HTML字节不同，导致ETag失效、协商缓存永远不命中 - 确保每次构建的HTML都包含唯一标识，例如注入
<meta name="build-timestamp" content="202610150330">，便于排查缓存是否来自旧构建
容易被忽略的离线/Service Worker 场景
当项目启用 Service Worker 时，HTML缓存策略会和SW的 fetch 逻辑产生叠加效应：
- 若SW脚本里写了
event.respondWith(caches.match(event.request))且未排除HTML请求，就会把旧HTML从缓存中直接返回，绕过所有HTTP头 - 推荐做法：在SW中对HTML请求走网络优先（
networkFirst），并配合cache busting查询参数（如/index.html?sw=20261015）强制跳过磁盘缓存 - 注意
workbox.routing.registerRoute的正则匹配顺序——HTML路由规则必须放在通用通配符之前，否则会被兜底策略捕获
真正棘手的不是设哪个头，而是确认「谁在缓存HTML」：浏览器？CDN？反向代理？Service Worker？Nginx？每层都可能独立生效。上线前务必用 curl -I 和 Chrome DevTools 的 Network → Headers 面板逐层验证响应头，别只信文档或配置注释。
