HTML5的Cache-Control和Expires无法控制Service Worker缓存，因其仅影响浏览器基础缓存层，而SW缓存需手动管理；Workbox依赖revision哈希更新，手写SW须自行比对版本或hash。
HTML5 的 Cache-Control 和 Expires 不能控制 Service Worker 缓存
很多人以为在 HTML 中写 <meta http-equiv="Cache-Control" content="no-cache"> 就能管住离线资源，其实它只影响 HTTP 请求的浏览器基础缓存层，对 Service Worker 自己 fetch 并 put 到 cacheStorage 中的资源完全无效。Service Worker 的缓存是手动管理的，得靠代码显式读写。
常见错误现象：
– 页面更新了，但旧 JS/CSS 仍从 cacheStorage 返回
– 清除浏览器缓存后，离线页还是旧版
– workbox.precaching 没触发更新，因为 revision 没变
- HTTP 响应头（如
Cache-Control: max-age=3600）只约束「网络请求是否走浏览器磁盘缓存」，不约束 SW 的caches.open() - 若用 Workbox，它默认靠文件内容哈希生成
revision字段来判断资源是否变更；手写 SW 则必须自己比对版本号或 hash - 开发时禁用缓存（Chrome DevTools → Network → ✅ Disable cache）仅影响网络请求，不影响
caches.match()查找结果
Service Worker 更新失败的三个典型卡点
SW 脚本本身更新失败，会导致整个离线策略停滞。不是“注册即生效”，而是有一套严格的状态流转机制。
- 新 SW 文件必须与旧版字节不同（哪怕只多一个空格），否则浏览器直接忽略更新尝试
- 旧 SW 正在控制页面时，新 SW 会进入
waiting状态，不会自动激活；需调用skipWaiting()或等用户关闭所有页面再刷新 -
navigator.serviceWorker.register('/sw.js')成功不代表激活成功；要用controllerchange事件监听实际接管时机
示例：在新 sw.js 开头加 self.skipWaiting(); 并监听 activate 事件清理旧 cache：
立即学习“前端免费学习笔记（深入）”；
self.addEventListener('activate', event => {
event.waitUntil(
caches.keys().then(keys =>
Promise.all(keys.map(key =>
key !== 'v2-cache' && key.startsWith('v') ? caches.delete(key) : Promise.resolve()
))
)
);
});
Workbox precache 如何真正触发资源更新
用 workbox.precaching.precacheAndRoute([]) 时，资源不会自动更新——除非你让 Workbox 检测到「同一 URL 对应的 revision 变了」。
- Webpack/Vite 插件（如
workbox-webpack-plugin）会在构建时注入哈希，生成类似{url: "main.a1b2c3.js", revision: "a1b2c3"}的清单；部署新包后 revision 改变，Workbox 才会替换缓存 - 手写清单时，别硬编码
revision；改用workbox.core.cacheNames.precache配合动态生成，或直接用injectManifest模式让插件注入 - 如果跳过 revision（设为
null或删掉字段），Workbox 会退化为「仅首次 precache，永不更新」
错误写法：{url: "app.js", revision: "1.0"} → 永远不更新
正确做法：构建时生成 {url: "app.js", revision: "f8a7e2d4"}，且确保每次构建哈希唯一
调试离线更新最有效的三步检查法
别猜，直接看运行时行为。DevTools 的 Application → Cache Storage 和 Service Workers 面板信息很全，但容易忽略关键状态。
- 打开 Application → Service Workers，确认「Current worker」指向的是你期望的版本；点击「Update on reload」强制拉新 SW（注意：这不等于激活）
- 在 Cache Storage 里展开对应 cache 名称，逐个点开资源，看 response body 是否为最新内容；若仍是旧 HTML，说明 precache 没走，或 SW 的
fetch事件没命中该 URL - 在 Console 执行
caches.keys().then(console.log)，确认旧 cache 名是否残留；再查navigator.serviceWorker.controller是否为null（未激活）或指向旧脚本
最容易被忽略的一点：HTML 文件本身通常不在 precache 列表里（因常变动），而是靠 runtime caching 规则匹配；若规则写成 new RegExp('/.*\.html/') ，可能把 /admin.html 也缓存了，却忘了设置 staleWhileRevalidate，导致 HTML 永远不更新。
