本地开发时Service Worker常不生效，因更新需字节变化且仅下次加载尝试安装；须用DevTools勾选Update on reload、手动unregister，并配对使用skipWaiting()与clients.claim()。
如何正确注册 Service Worker
注册是启动一切的前提，但容易因路径、作用域或执行时机出错：
-
navigator.serviceWorker.register()必须在页面加载后、且navigator.serviceWorker可用时调用（常见于window.addEventListener('load', ...)） - 注册路径默认以 HTML 文件所在目录为基准，若
sw.js放在根目录，需显式写成navigator.serviceWorker.register('/sw.js')，否则可能注册到子路径下导致作用域过窄 - 注册失败不会抛异常，需监听
registration.onupdatefound或检查console中的 “failed to register” 提示
Service Worker 的三大核心功能是什么
它本质是一个可编程的网络代理，关键能力只有三个，其他都是衍生：
-
离线缓存控制：通过
caches.open()+cache.put()预存资源，在install事件中完成；后续用fetch事件拦截请求并从缓存匹配 -
网络请求拦截与响应定制：在
fetch事件中调用event.respondWith()，可返回缓存响应、发起新fetch()、甚至生成new Response() -
后台消息通信与生命周期管理：支持
postMessage()与主页面双向通信；activate阶段常用来清理旧缓存（caches.delete()），避免缓存爆炸
常见的缓存策略怎么选
没有“万能策略”，选错会导致白屏、旧资源不更新或反复请求：
-
Cache-First：优先读缓存，失败再 fetch；适合静态资源（JS/CSS/图标），但需配合
activate清理旧版本 -
Network-First：先发网络请求，超时或失败才 fallback 到缓存；适合内容页，但需设置合理 timeout（浏览器无原生 timeout，得用
AbortController） -
Stale-While-Revalidate：立即返回缓存，同时后台 fetch 更新缓存；用户体验好，但代码稍复杂，需在
fetch中并发处理两个响应流
self.addEventListener('fetch', event => {
const url = new URL(event.request.url);
if (url.origin === location.origin && url.pathname.startsWith('/api/')) {
// API 请求走 Network-First
event.respondWith(
fetch(event.request).catch(() => caches.match(event.request))
);
} else {
// 静态资源走 Cache-First
event.respondWith(
caches.match(event.request).then(res => res || fetch(event.request))
);
}
});
为什么本地开发时经常“不生效”
这是最常被卡住的环节，根本原因在于 Service Worker 的作用域和更新机制：
立即学习“Java免费学习笔记（深入）”；
- 每次修改
sw.js后，浏览器不会立即启用新版本——它只在下次页面加载时“尝试安装”，且仅当文件内容字节不同才触发更新（空格、注释变化无效） - Chrome DevTools 的
Application > Service Workers面板里勾选Update on reload和Unregister手动清除，是调试必备操作 -
localhost允许 HTTP，但某些安卓 WebView 或旧版 iOS Safari 仍会拒绝注册，务必真机测试 -
skipWaiting()和clients.claim()要配对使用，否则新 SW 安装后不会接管当前页面，导致“看似注册成功却没缓存”
