Chrome DevTools 没有独立“Cache”面板，核心缓存调试依赖 Network 面板（查缓存命中与响应头）和 Application 面板（管理 Cache Storage 与 Service Workers），配合三步验证法可精准定位缓存问题。
Chrome DevTools 没有独立的“Cache”面板。这是个常见误解——DevTools 中与缓存调试直接相关的核心面板是 Network（网络）面板，配合 Application（应用）面板中的 Cache Storage 和 Service Workers 来协同分析。
真正能帮你看清缓存策略、验证是否命中、定位缓存失效问题的，是这几个关键位置和操作：
Network 面板：看请求是否走缓存、走哪种缓存
这是最常用也最直观的入口。打开 DevTools（F12），切换到 Network 标签页后：
确保勾选 Disable cache（仅在调试时启用，避免本地缓存干扰判断）
-
刷新页面，观察每个资源的 Size 列：
- 显示
from cache或from disk cache→ 强缓存命中（未发请求） - 显示
304 Not Modified→ 协商缓存生效（发了请求，但服务器确认未变） - 显示具体字节数（如
12.4 KB）→ 完全未命中缓存，重新下载
- 显示
-
点击任一请求，在 Headers 选项卡中检查响应头：
-
Cache-Control: max-age=3600→ 强缓存有效期 1 小时 -
ETag: "abc123"+If-None-Match请求头 → ETag 协商机制在工作 -
Last-Modified: Wed, 01 Jan 2025...+If-Modified-Since→ 时间戳协商 -
Cache-Control: no-cache→ 强制跳过强缓存，但允许协商缓存 -
Cache-Control: no-store→ 完全不缓存，每次都是全新请求
-
小技巧：右键点击请求列表标题栏（如 Name、Status），勾选 "Cached" 列，可快速筛选出所有被缓存的资源。
Application 面板：查 Cache Storage 和 Service Worker 缓存
如果你用了 PWA 或自定义缓存逻辑（比如 cache.put()），这部分才是真实落地的地方：
切换到 Application → Cache Storage
左侧会列出所有已注册的缓存名称（如
my-app-v1,runtime-cache）点击某个缓存，右侧显示其中存储的所有 URL 和响应详情
可右键某条缓存项选择 "Delete"，或点击顶部 "Clear all" 清空整个缓存
-
同时检查 Application → Service Workers：
- 查看当前激活的 worker 是否启用（Enable Update on Reload 勾选可强制更新）
- 点击 “Update on reload” 按钮可触发重新注册和缓存刷新
- 若有
skipWaiting()或clients.claim()调用失败，旧缓存可能一直残留
实操建议：三步快速验证缓存行为
- 第一步：关闭所有缓存干扰 → 勾选 Network 的 Disable cache，禁用 Service Worker（Application → Service Workers → Unregister）
- 第二步：正常刷新 → 观察哪些资源返回 200（新下载）、哪些是 304（协商命中）
- 第三步：恢复缓存 → 取消 Disable cache，再刷新，对比 Size 列是否出现
from cache；再进 Cache Storage 看对应资源是否存在
不复杂但容易忽略
