DevTools 缓存不更新排查路线
按 DevTools 面板协作方式梳理缓存不更新排查路径,覆盖 HTTP 缓存、memory/disk cache、Cache Storage 和 Service Worker。
#type / synthesis
#status / growing
#tech / dev / frontend
#platform / browser
#resource / chrome-devtools
[!info] related notes
DevTools 缓存不更新排查路线
范围
这条路线处理的是:
- 明明发了新版本,页面却还是旧内容
- 普通刷新和强刷结果不一样
- 某些资源一直返回旧文件
- 离线缓存或 Service Worker 让页面长期卡旧版本
为什么要放在一起理解
“缓存不更新”不是一个单一问题,它可能来自:
- HTTP 强缓存 / 协商缓存
- memory cache / disk cache
- Cache Storage
- Service Worker 生命周期
如果不先分层,排查很容易在错误层级来回打转。
排查路线
第一步:先判断请求到底有没有出网
打开 Network 面板,重点看:
304from memory cachefrom disk cache- 普通刷新、强刷、Disable cache 的差异
如果连网络都没出,就先不要怀疑服务端部署。
第二步:看缓存语义和响应头
继续在 Network 看:
Cache-ControlETag/Last-ModifiedVary(如果缓存行为不符合预期,可能是 Vary 不匹配)→ Vary 与缓存键Age(如果通过 CDN/代理,检查已消耗的新鲜时间)→ Age、Date 与新鲜度计算- 资源 URL 是否变了
第三步:确认是不是 Service Worker 接管了
如果表现不像单纯 HTTP 缓存,就去:
重点区分:
- 请求是浏览器缓存命中
- 还是 Service Worker 主动返回旧资源
第四步:回到 Application 看本地缓存仓库
打开 Application 面板:
- Cache Storage 里是否还放着旧响应
- Service Worker 当前是不是旧版本
- 站点数据清理后行为是否变化
第五步:最后才判断是不是发布和构建问题
只有前面几层看清后,再回到工程层判断:
- 文件指纹是否正确 → 缓存失效与部署策略
- HTML 是否引用了旧资源
- Service Worker 更新策略是否合理
- CDN 是否还在服务旧版本(检查 CDN purge 状态) → CDN 边缘缓存
对比与易混淆点
Disable cache不等于清空所有缓存304说明走了协商缓存,不等于“完全没请求”- 页面旧内容可能来自 HTTP 缓存,也可能来自 Service Worker 或 Cache Storage