HTML中如何设置合理的浏览器缓存策略
先说一个核心结论：HTML文件本身无法设置缓存策略，所有有效的控制都必须通过HTTP响应头来完成。至于那个常被提起的标签，在现代浏览器里基本已经“退休”了，完全不起作用。
为什么
这个标签是HTML 4时代的产物，初衷是为了兼容早期的Internet Explorer。但时代变了，如今主流的Chrome、Firefox、Safari等浏览器，早在2010年代就已经彻底忽略了它对缓存行为的任何影响。它既不会触发条件请求（比如带上If-None-Match头），也无法改变浏览器是否从磁盘或内存加载HTML的决定。继续写它，最大的风险是制造一种“我已经配置好了”的安全假象，反而掩盖了服务端真实配置缺失的根本问题。
Nginx中正确配置HTML缓存的最小必要写法
对于像index.html这类经常更新的入口文件，最推荐的策略是使用协商缓存，而不是简单粗暴地禁用所有缓存。这样做的好处是，既能确保用户不会被困在旧版本里，又能利用内存缓存来提升首屏加载速度。
下面是一个在Nginx中的参考配置：
location = /index.html {
add_header Cache-Control "no-cache, must-revalidate, max-age=0";
add_header ETag "";
expires epoch;
}
我们来拆解一下这几行配置的含义：
no-cache：这个词有点误导性，它的意思不是“不缓存”，而是“使用前必须校验”。浏览器仍然会缓存文件，但下次请求时会自动带上If-None-Match这样的校验头。expires epoch：这是Nginx的语法，效果等同于设置Expires: Thu, 01 Jan 1970 00:00:01 GMT，目的是强制让强缓存立即失效。- 空的
ETag：这会让Nginx自动生成一个基于文件内容的校验值。如果你的后端服务能提供Last-Modified头，也可以考虑使用它。
需要特别警惕的是：千万不要对HTML文件使用类似public, max-age=31536000（一年）这样的长期强缓存策略。尤其是在单页面应用（SPA）场景下，这极易导致引用的JS或CSS文件版本错配，结果就是页面白屏或者样式一片混乱。
如何验证HTML缓存策略是否生效
验证方法很重要，别被表象骗了。在地址栏按回车或者按F5刷新，走的可能是内存缓存，或者会强制发起校验，结果并不完全可靠。
唯一靠谱的验证流程是：打开Chrome开发者工具 → 切换到“Network”（网络）面板 → 刷新页面 → 在请求列表中找到index.html这一项 → 仔细观察它的“Response Headers”（响应头）和“Status”（状态）列。
立即学习“前端免费学习笔记（深入）”；
- 如果看到响应头里有
Cache-Control: no-cache, must-revalidate, max-age=0，并且状态码是304 Not Modified，那么恭喜你，协商缓存正在正常工作。 - 如果状态码是
200 OK，但“Size”列显示为from disk cache，这可不是好事，它意味着强缓存意外生效了，说明你的配置可能有问题。 - 如果状态码是
200 OK，且“Size”列显示的是具体的字节数（比如2.4 KB），那说明文件每次都被重新下载了。这可能是因为缓存头根本没生效，需要检查Nginx配置是否漏加了add_header指令，或者被上游（upstream）的配置给覆盖了。
最后，还有一个在复杂发布流程中极易被忽略的环节：HTML的缓存策略必须和前端构建产物的版本管理联动起来考虑。举个例子，你用Webpack打包时给JS和CSS文件加上了哈希后缀，但如果承载这些引用的index.html文件被CDN长期缓存，用户拿到的就还是一个指向旧哈希文件的老HTML。这样一来，版本更新就失效了。所以说，HTML文件本身必须采用短缓存或协商缓存策略，这往往是整个前端发布链路中最脆弱、也最关键的一环。
