第一眼应盯住Chrome DevTools Network面板的状态码（200/304/from disk cache）和响应头：Cache-Control是否匹配配置、ETag/Last-Modified是否存在、Vary是否引发缓存键膨胀；再用curl -I直验服务端真实响应，排除浏览器干扰，并检查CDN与源站策略冲突及HTML内联动态内容对缓存的影响。
看Network面板里状态码和响应头是否匹配预期
生产环境验证HTML缓存，第一眼就该盯住Chrome DevTools的Network标签页。不是看页面有没有变，而是看每次请求的真实行为：状态码是不是200（强缓存命中）、304（协商缓存命中），还是200但没带from disk cache——后者说明缓存根本没生效。
重点检查响应头中这几个字段：
-
Cache-Control：值是否符合部署配置？比如静态HTML设了public, max-age=3600，但实际返回却是no-cache，那一定是Nginx或后端中间件覆盖了它 -
ETag或Last-Modified：存在且不为空，才可能触发协商缓存；如果连这两个都没有，no-cache也白搭 -
Vary：尤其当用了Accept-Encoding或User-Agent时，它会让缓存键变复杂，容易导致“看似缓存了，实则每次都是新缓存”
用curl绕过浏览器，确认服务端真实输出
浏览器有启发式缓存、内存缓存、预加载等干扰项，curl能剥离这些，直击服务端响应。执行这条命令就能看到原始头信息：
curl -I https://yoursite.com/index.html
注意几个关键点：
立即学习“前端免费学习笔记（深入）”；
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 如果返回
HTTP/2 200但没Cache-Control，说明后端代码（如PHP模板、Express路由）漏写了头，或者被CDN/反向代理删掉了 - 如果返回
Cache-Control: no-store，但你本意是no-cache，那就是配置写错了——no-store会彻底禁用所有缓存，连协商都不走 - 加
-H "Cache-Control: no-cache"模拟浏览器强制验证，看是否返回304；不返回，说明ETag没生成或校验逻辑失效
检查CDN与源站缓存策略是否冲突
很多故障出在CDN层“自作主张”。比如你源站返回Cache-Control: private, max-age=60，但CDN配置成“对所有.html统一缓存1小时”，那用户看到的就是CDN的旧副本，跟源站完全无关。
验证步骤很简单：
- 先查CDN控制台，确认HTML路径是否被显式设置了缓存规则
- 用
curl -v看响应头里有没有X-Cache: HIT或类似字段，有就是CDN在说话 - 临时在CDN上把HTML路径设为“不缓存”，再curl对比，如果这时返回正常了，问题就定位清楚了
留意HTML内联脚本和动态内容对缓存有效性的影响
缓存HTML本身不难，难的是它里面嵌的动态部分。比如一个<script>var timestamp = <?= time() ?></script>，每次渲染时间都不同，会导致ETag计算值总变，协商缓存永远不命中。
这类问题不会报错，但会让缓存形同虚设。排查时重点关注：
- 模板里是否混入了时间戳、随机数、用户ID等每次请求都不同的变量
- 是否用了
html-webpack-plugin的minify: 'auto'，而压缩逻辑又依赖了当前构建时间——这会让HTML文件内容每次都不一样，强缓存直接失效 - 后端是否对HTML做了Gzip但没同步设置
Vary: Accept-Encoding，导致CDN把压缩版和未压缩版当成同一个缓存键
最隐蔽的坑是：缓存看起来生效了，但实际只是“缓存了错误的内容”。比如首页HTML缓存了1小时，而它通过AJAX加载的数据却没缓存，用户看到的是“旧壳+新数据”，体验割裂。这时候要分开验证HTML本身和它依赖的API响应头。
