Service Worker注册必须满足HTTPS（或localhost）安全上下文，否则直接失败；常见失效原因包括sw.js路径404、跨源注册、scope未覆盖目标路径、install事件中cache.addAll()原子性失败或未正确waitUntil。
Service Worker 必须在 HTTPS 下注册，HTTP 环境下会直接失败 —— 这是面试常被忽略但上线必踩的硬性前提。
为什么 register() 调用后 Service Worker 没生效？
常见现象：调用 navigator.serviceWorker.register('/sw.js') 后控制台无报错，但后续请求未被拦截，install 事件也不触发。
- 当前页面不是 HTTPS（本地
http://localhost除外，Chrome/Firefox 允许，但生产环境必须 HTTPS） -
sw.js文件响应状态不是200（比如返回404或301，浏览器静默失败） -
sw.js与页面不在同一源（例如页面在https://a.com，却尝试注册https://b.com/sw.js） - 页面已存在激活中的 Service Worker，新版本处于
waiting状态，需手动skipWaiting()或刷新两次
caches.open() 和 cache.addAll() 的典型误用
预缓存阶段写法看似简单，但容易导致安装失败或资源缺失：
-
cache.addAll()中路径必须是**相对当前 sw.js 的路径**，不是 HTML 页面的路径；例如sw.js在根目录，要缓存/assets/app.js，就得写'/assets/app.js'，不能写'assets/app.js'（少斜杠 → 404） -
cache.addAll()是原子操作：任一资源加载失败，整个缓存就中止，install事件 reject，Worker 不会进入激活态 - 不建议在
install阶段缓存动态路由（如'/user/123'），应改用fetch事件中按需缓存 + 策略选择
Cache API 缓存策略怎么选？
离线体验好坏，取决于你对不同资源类型用了什么策略。别一股脑全上 Cache First：
立即学习“前端免费学习笔记（深入）”；
-
Cache First：适合静态资源（/main.css,/logo.png），但需配合版本号更新缓存（如'v2'）并清理旧缓存 -
Network First：适合带用户数据的页面（如/dashboard），先尝试网络，失败再 fallback 到缓存（用event.respondWith(fetch(...).catch(...))） -
Stale-while-revalidate：适合内容型页面（如新闻详情），立即返回缓存，后台悄悄更新，下次访问就是新内容 - 千万别对
/api/类接口用Cache Only，否则用户永远看不到新数据
Manifest.json 里哪些字段是 PWA 可安装的必要条件？
Chrome / Edge 要求至少满足三项才显示“添加到主屏幕”提示：
-
name或short_name（二者至少一个） -
icons数组中至少含一个192x192和一个512x512PNG 图标（MIME 类型必须是image/png） -
start_url（必须可访问，且最好返回200） - 额外注意：
display: 'standalone'或'fullscreen'才能隐藏地址栏；theme_color控制标题栏颜色，但不影响安装资格
真正难的不是写出来，而是让 install 成功、activate 稳定、fetch 不漏请求、缓存不 stale 也不 stale 过头 —— 每个环节都依赖对生命周期和缓存语义的精确理解，而不是套模板。
