[!info] related notes

• 所属 MOC: DevTools Network MOC, DevTools Application MOC
• 前置概念: Service Worker 与 Cache API
• HTTP 缓存: 缓存调试
• 生命周期: Service Worker 调试
• 排障路线: 缓存不更新排查路线

DevTools Service Worker 请求调试

症状

• API 或静态文件一直是旧版本；
• 离线行为与预期不一致；
• Network 显示请求来自 Service Worker；
• 后端已经修改但浏览器看不到；
• 新 worker 已下载但页面仍由旧 worker 控制。

证据 1：页面是否被 Service Worker 控制

Application 面板先确认：

• registration 是否存在；
• active / waiting worker；
• scope；
• 当前页面是否属于该 scope。

没有控制关系，就不要继续把所有缓存问题归因于 SW。

证据 2：Network 的响应来源

如果请求显示由 Service Worker 处理，继续问：

fetch handler 最终返回的是 Cache Storage、network fetch，还是 fallback response？

只看到 status 200 不足以判断来源。

证据 3：Cache Storage

检查与该 request 匹配的 cache entry：

• cache name；
• request URL；
• stored response；
• 是否属于旧版本 cache；
• key 是否包含 query / method 等真正 identity。

证据 4：绕过 SW 做对照实验

临时绕过 Service Worker 或 unregister 后重新请求。

如果问题消失：

→ SW routing/cache strategy 高度可疑。

如果问题仍然存在：

→ 回到普通 HTTP cache、CDN、server 或 app state。

常见根因

Cache-first 永远返回旧资产

没有版本化 URL / cache name / update policy。

新 worker waiting

旧页面仍被旧 active worker 控制。

fetch handler 范围过宽

把本不应该缓存的 API 也纳入 stale cache strategy。

离线 fallback 误命中

网络失败时返回了不适合当前请求的 cached response。

SW 与 HTTP cache 双层叠加

即使 Cache Storage 正确，worker 的 network fetch 仍可能命中 HTTP cache。

修复原则

• 静态构建资产使用 fingerprint；
• cache name/version 有明确生命周期；
• API strategy 与静态 asset strategy 分开；
• 更新策略有 activate/claim 设计；
• 必须能从 Network/Application 解释每次 response 的真实来源。

迁移检查

给一个 PWA：“服务器 API 已返回新数据，但页面永远显示昨天的数据”。

闭卷完成：

1. 证明页面是否受 SW 控制；
2. 判断 response 是否来自 SW；
3. 检查 Cache Storage；
4. 做 bypass/unregister 对照；
5. 区分 SW cache 与 HTTP cache；
6. 给出一个不会靠“用户清站点数据”的长期修复。