Chrome DevTools无独立Cache面板，缓存调试依赖Network面板（查Size列和Status码）与Application面板（管Cache Storage和服务工作线程），配合curl验证原始响应及逐层排查CDN、Service Worker等干扰。
看 Network 面板的 Size 列和 Status 码
缓存是否生效，不靠猜，也不靠刷新后“看起来像新”，而是看 Chrome DevTools 的 Network 面板里两个关键字段：Size 和 Status。普通刷新（F5 或地址栏回车）才走真实缓存逻辑；Ctrl+Shift+R 会强制跳过所有缓存，结果无效。
常见组合含义：
-
Size显示from memory cache或from disk cache→ 缓存命中，且未发请求 -
Status是304 Not Modified→ 发了条件请求（带If-None-Match或If-Modified-Since），服务端确认没变，复用本地副本 -
Status是200且Size是具体字节数（如2.4 KB）→ 缓存失效或被绕过，完整重下
检查 Response Headers 是否按预期下发
配置改了，但服务器未必真发出去。在 Network 面板点开 index.html 请求 → 切到 Headers → 展开 Response Headers 区域，确认以下字段存在且值正确：
- 有
Cache-Control：比如no-cache, must-revalidate, max-age=0或public, max-age=3600 - 若用了
Expires，它必须是 GMT 格式，且时间早于当前时刻（如Expires: Thu, 01 Jan 1970 00:00:01 GMT） - 有
ETag或Last-Modified→ 协商缓存才可能触发304
注意：Cache-Control 优先级高于 Expires；如果两者冲突，浏览器只认 Cache-Control。
立即学习“前端免费学习笔记（深入）”；
用 curl 模拟无浏览器干扰的原始响应
浏览器 UI 层有内存缓存、预加载、Service Worker 等干扰项，容易误判。用 curl 直接抓原始 HTTP 响应最干净：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
curl -I https://yoursite.com/index.html
观察输出中是否有你配置的 Cache-Control、ETag 等头。如果缺失，说明 Nginx/Apache/CDN 配置没生效，或者被上层代理覆盖（比如 CDN 默认加了 Cache-Control: public, max-age=3600，把你后端的头给替换了）。
额外验证技巧：
- 加
-H "Cache-Control: no-cache"模拟带验证头的请求，看是否返回304 - 用
curl -v查看完整请求/响应流程，确认有没有重定向或中间层改写头
别忽略 Service Worker 和 CDN 的双重缓存层
即使你把 Nginx 的 Cache-Control 改成 no-store，用户仍可能看到旧 HTML——因为：
- Service Worker 的
caches.open('v1')里还存着上一版index.html，且没调用caches.delete('v1') - CDN 节点缓存了旧响应，而你的源站响应头更新后，CDN 没触发自动刷新（尤其当 CDN 缓存键忽略查询参数或部分 header 时）
验证时务必确认：
- 打开
Application → Service Workers，看是否已激活新版本，并勾选Update on reload测试 - 访问
https://yoursite.com/index.html?_t=xxx（带随机参数），再查Network，排除 CDN 键命中问题
真正难调试的从来不是“怎么配”，而是“哪一层先截胡了”。每次改完缓存策略，都要从网络链路最外层（CDN）往里逐层确认，否则很容易在浏览器里反复刷新却毫无进展。
