[!info] related notes

• 所属 MOC: 浏览器开发者工具 MOC, DevTools Network MOC, DevTools Application MOC
• 相关概念: 缓存调试, Service Worker 请求调试, Service Worker 调试, IndexedDB 与 Cache Storage 调试
• 易混淆概念: 浏览器缓存体系, Service Worker 与 Cache API

DevTools 缓存不更新排查路线

范围

这条路线处理的是：

• 明明发了新版本，页面却还是旧内容
• 普通刷新和强刷结果不一样
• 某些资源一直返回旧文件
• 离线缓存或 Service Worker 让页面长期卡旧版本

为什么要放在一起理解

“缓存不更新”不是一个单一问题，它可能来自：

• HTTP 强缓存 / 协商缓存
• memory cache / disk cache
• Cache Storage
• Service Worker 生命周期

如果不先分层，排查很容易在错误层级来回打转。

排查路线

第一步：先判断请求到底有没有出网

打开 Network 面板，重点看：

• 304
• from memory cache
• from disk cache
• 普通刷新、强刷、Disable cache 的差异

如果连网络都没出，就先不要怀疑服务端部署。

第二步：看缓存语义和响应头

继续在 Network 看：

• Cache-Control
• ETag / Last-Modified
• Vary（如果缓存行为不符合预期，可能是 Vary 不匹配）→ Vary 与缓存键
• Age（如果通过 CDN/代理，检查已消耗的新鲜时间）→ Age、Date 与新鲜度计算
• 资源 URL 是否变了

这一层对应 缓存调试 和 请求与响应检查。

第三步：确认是不是 Service Worker 接管了

如果表现不像单纯 HTTP 缓存，就去：

• Service Worker 请求调试
• Service Worker 调试

重点区分：

• 请求是浏览器缓存命中
• 还是 Service Worker 主动返回旧资源

第四步：回到 Application 看本地缓存仓库

打开 Application 面板：

• Cache Storage 里是否还放着旧响应
• Service Worker 当前是不是旧版本
• 站点数据清理后行为是否变化

第五步：最后才判断是不是发布和构建问题

只有前面几层看清后，再回到工程层判断：

• 文件指纹是否正确 → 缓存失效与部署策略
• HTML 是否引用了旧资源
• Service Worker 更新策略是否合理
• CDN 是否还在服务旧版本（检查 CDN purge 状态） → CDN 边缘缓存

对比与易混淆点

• Disable cache 不等于清空所有缓存
• 304 说明走了协商缓存，不等于“完全没请求”
• 页面旧内容可能来自 HTTP 缓存，也可能来自 Service Worker 或 Cache Storage

迁移检查

场景：发布新版本后只有部分用户继续看到旧页面，强刷后恢复。

不看正文：

1. 区分 memory/disk cache、304、CDN、Cache Storage、Service Worker 五层证据；
2. 为什么 Disable cache 只能排除一部分缓存路径？
3. 如果请求显示 from ServiceWorker，下一步查什么？
4. 如果 HTML 引用旧 hashed chunk，但资源本身已更新，问题更像部署链哪一层？
5. 给出长期修复而不是“让用户清缓存”。

Related notes

• 浏览器开发者工具 MOC
• DevTools Network MOC
• DevTools Application MOC
• 缓存调试