判断HTML是否真正复用缓存，应观察Network面板中HTML请求的Status和Size：304表示协商缓存命中；from memory/disk cache表示强缓存命中、无网络请求；200加具体字节数说明未命中缓存。
看 Network 面板里 HTML 请求是否走了 304 或直接 from memory cache
浏览器是否真正复用 HTML 缓存，不看响应头有没有 Cache-Control，而要看实际请求行为。打开 DevTools → Network → 刷新页面，找到主 HTML 请求（如 /index.html），观察它的 Status 和 Size 列：
-
200 OK（且 Size 是几 KB）→ 没走缓存，或缓存已失效 -
304 Not Modified→ 走了协商缓存：浏览器发了If-None-Match或If-Modified-Since，服务器确认没变，返回空体 -
200 OK（Size 显示from memory cache或from disk cache）→ 强缓存命中，完全没发网络请求
注意：如果 HTML 响应头是 Cache-Control: no-cache，你几乎总会看到 304；如果是 max-age=300，前 5 分钟内刷新应该直接显示 from memory cache。
检查 HTML 响应头是否被 CDN 或反向代理覆盖
本地 Nginx 或后端设了 Cache-Control: public, max-age=300，但线上看不到效果？大概率是 CDN（如 Cloudflare、阿里云 CDN）或负载均衡器（如 SLB、ALB）把响应头重写了。这类中间层默认会忽略源站的缓存头，按自己的规则处理。
- 在 Network 面板点开 HTML 请求 → Headers → Response Headers，确认
Cache-Control值和你预期一致 - 如果值变成
no-cache或max-age=0，说明 CDN 控制台没配缓存规则，或配了“绕过缓存”策略 - Cloudflare 默认对 HTML 路径（
/*）设为“标准缓存”，但会忽略 Cookie；若 HTML 含登录态，需手动开启 “Cache Everything” 并配置缓存键（Cache Key）包含Cookie字段
别信后端日志里打印的 header —— 它只反映源站输出，不等于浏览器最终收到的。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
验证 ETag 是否稳定，避免协商缓存永远不命中
当 Cache-Control 过期后，浏览器靠 ETag 或 Last-Modified 发起条件请求。但如果每次生成的 ETag 都不同，哪怕 HTML 内容没变，也会触发完整重传（200 OK + 全量 body），比不缓存还糟。
- 用
curl -I https://yoursite.com/index.html多次请求，看ETag值是否一致 - 常见破坏稳定性的情况：
<!-- build:20261013 -->这类时间戳注释、<script>console.log(Date.now())</script>、服务端模板里插入微秒级时间 - Nginx 默认
etag on是基于文件 mtime 的，对动态 HTML 不适用；建议关闭 ETag，改用稳定的Last-Modified（例如从 git commit 时间生成）
一个 ETag 总在变的 HTML，no-cache 就等于 no-cache-and-never-hit。
对比首屏时间（FCP）和重复访问的 TTFB 差异
HTML 缓存对性能的影响，最终要落到用户可感知的指标上。重点不是“缓存开了没”，而是“第二次访问快了多少”：
- 首次访问 FCP：受 DNS、TCP、TLS、TTFB、HTML 下载、解析、渲染链路影响
- 重复访问 FCP：如果 HTML 走强缓存（
from memory cache），TTFB 直接降为 0ms，FCP 通常能提前 200–600ms（尤其弱网下） - 但如果 HTML 走
304，TTFB 仍存在（哪怕只有 50ms），且多一次 HTTP 往返，FCP 提升有限 - 用 Lighthouse 的 “Performance” 报告对比两次运行，重点关注 “Time to First Byte” 和 “First Contentful Paint” 的 delta
最易被忽略的是：HTML 缓存收益只在重复访问时体现，而很多 A/B 测试或监控只看首屏 —— 这会让你误判缓存是否生效。
