HTML5的Cache-Control和Expires无法控制Service Worker缓存，因其仅影响浏览器基础缓存层，而SW缓存需手动管理；Workbox依赖revision哈希更新，手写SW须自行比对版本或hash。
HTML5 的 Cache-Control 和 Expires 不能控制 Service Worker 缓存
很多人以为在 HTML 中写 就能管住离线资源，其实它只影响 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：
立即学习“前端免费学习笔记（深入）”；
