Network面板通过Status和Size字段直观反映HTML缓存状态：(from cache)表示强缓存生效；304且TTFB为0说明协商缓存命中；轮询检测更新时需强制禁用协商缓存，否则fetch可能静默返回空响应体。
看 Network 面板里的 Status 和 Size 最直接
浏览器不告诉你“这次 HTML 命中了缓存”，但 Network 面板会用状态码和尺寸字段暴露一切。关键不是猜，是盯住 index.html 这一行：
- Status 显示
(from cache)或(from disk cache)：强缓存生效，没发请求，性能最优 - Status 是
304且 TTFB - Status 是
200且 Size 列显示具体字节数（比如12.4 KB）：缓存完全失效，每次都在重新下载 HTML —— 这是首屏变慢的典型信号 - 注意
X-Cache: HIT或X-CDN-Cache: HIT响应头：说明 CDN 层也命中了，叠加效果明显；若为MISS，问题可能出在 CDN 配置而非浏览器
用 performance.getEntriesByType("navigation") 捕获真实加载行为
前端代码能拿到的最可靠指标，不是“有没有缓存”，而是“这次到底下了多少字节”。重点看 transferSize 和 responseStart - fetchStart：
-
transferSize === 0：基本可断定 HTML 从本地缓存读取（注意：协商缓存304场景下也可能为0，需结合 Status 判断） -
encodedBodySize显著小于首次加载值，且transferSize很小：说明复用了压缩后的缓存副本 -
fetchStart → responseStart差值大幅缩短（比如从 300ms 缩到 5ms）：缓存生效的时序证据 - 别只看
domContentLoadedEventEnd：它受 JS 执行影响大，缓存问题要先锁定网络层表现
服务端日志必须和服务端缓存头对齐
前端看到的 200 不等于服务端真没缓存——可能 Nginx 返回了 200，但实际走的是 upstream 缓存。盲信前端数据会漏掉关键链路：
- Nginx 配置里加
$upstream_http_cache_status到 access_log，记录每次 HTML 请求的真实缓存状态（HIT/MISS/EXPIRED） - 把日志中的
cache_status字段，和服务端响应头里的Cache-Control、ETag一起上报，和前端performance数据做时间戳关联 - 现象：服务端日志标
HIT，但前端transferSize > 0→ 说明 CDN 或中间代理层缓存被绕过，或客户端请求头带了Cache-Control: no-cache - 现象：服务端标
MISS，但前端 TTFB 极低 → 可能是 DNS 缓存、TCP 复用或 TLS 会话恢复造成的假象，不是 HTML 缓存生效
轮询检测更新时，fetch 必须禁用协商缓存
很多“检测 HTML 更新”方案失败，不是逻辑错，是被协商缓存静默劫持了：
立即学习“前端免费学习笔记（深入）”；
- 默认
fetch('/')可能触发304，返回空响应体，导致比对脚本拿不到新 HTML 内容 - 必须显式加
cache: 'no-cache'，并手动设请求头Cache-Control: no-cache，强制服务器返回完整200响应 - 某些 CDN（如 Cloudflare）会忽略客户端
Cache-Control，得在后台关闭“智能缓存”，或单独给/配置Cache-Control: no-store - 轮询间隔别设太短；移动端切后台时要用
document.hidden+visibilitychange暂停，否则白跑请求还耗电
实际最难控的，是服务端缓存策略和服务端模板渲染逻辑之间的耦合。比如一个缓存了 1 小时的 HTML 片段里嵌了 {{.CurrentUser.Name}}，用户 A 的名字就可能被缓存下来，透给用户 B。这种问题不会在 Network 面板报错，也不会让 transferSize 异常，但会导致 hydration mismatch 和数据污染。监控不能只盯“有没有缓存”，得盯“缓存的内容是否该被缓存”。
