Service Worker未触发waiting状态的主因是HTTP缓存导致浏览器未识别脚本变更，需通过添加时间戳注释、禁用强缓存解决；提示更新应在reg.waiting为true时触发，而非controllerchange；activate阶段须谨慎清理缓存并确保fetch兜底；WebView环境应避免无条件skipWaiting，改用静默更新策略。
Service Worker 检测到新版本但没触发 waiting 状态？
多数人卡在这一步：明明改了 SW 文件、重新注册了，navigator.serviceWorker.controller 还是旧的，页面也不弹提示。根本原因不是代码没写，而是浏览器没“看到”新版本——SW 的更新机制依赖 HTTP 缓存和脚本内容比对。fetch 到的 SW 脚本如果被 CDN 或本地缓存命中（哪怕只差一个空格），浏览器就认为“没变”，直接跳过更新流程。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 开发阶段在 SW 脚本末尾加注释或时间戳，例如
// v1.2.3-20240520，确保每次修改后 URL 内容字节不同 - 上线时禁用 SW 脚本的强缓存：
Cache-Control: no-cache, must-revalidate（通过服务器配置或构建工具注入 HTTP 头） - 不要靠
location.reload()强刷来“触发更新”——这只会让旧 SW 继续控制页面，新 SW 仍处于installed状态，不会自动升级
waiting 状态有了，怎么安全提示用户刷新？
当新 SW 进入 waiting，说明它已安装完成，但尚未激活（因为旧 SW 正在控制着已有页面）。这时不能直接 skipWaiting()，否则可能中断用户正在操作的表单或上传任务。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 监听
controllerchange事件仅用于检测“当前页面是否已被新 SW 控制”，不适用于提示更新——它只在激活后触发，用户已经错过了提示时机 - 正确做法是在
serviceWorker.ready后主动检查：if (reg.waiting) { showUpdatePrompt() } - 提示文案避免写“新版本已下载”，而应说“有新功能，刷新即可体验”，降低用户心理门槛；按钮文案用“立即刷新”而非“更新”，更符合用户直觉
用户点了刷新，但页面白屏或报错？
常见于 SW 在 activate 阶段执行了不兼容的缓存清理逻辑，比如 cache.delete() 删除了当前页面必需的资源，而新 SW 的 fetch 事件还没来得及接管请求。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
实操建议：
立即学习“前端免费学习笔记（深入）”；
-
activate中清理缓存前，先event.waitUntil()确保所有旧 cache 名称都明确列出，别用正则模糊匹配——误删会导致资源 404 - 新 SW 的
fetch事件必须能兜底：对 HTML 请求优先走网络（networkFirst），避免因缓存缺失导致白屏 - 上线前用 Chrome DevTools 的
Application > Service Workers面板手动触发skipWaiting+Update on reload组合测试，模拟真实更新链路
为什么 self.skipWaiting() 在某些机型上无效？
Android WebView、部分国产浏览器内核（如 X5）对 skipWaiting() 支持不完整，即使调用了，新 SW 也可能卡在 waiting 不激活。这不是代码 bug，是运行环境限制。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 不要在
install事件里无条件调用self.skipWaiting()—— 它只在你确定不需要旧 SW 继续服务时才该用（比如纯静态站点） - 对需要兼容 WebView 的场景，改用“静默更新 + 下次打开生效”策略：新 SW 安装后不强制切换，等用户关闭再打开页面时，由浏览器自动激活
- 可通过
navigator.userAgent检测 WebView 环境，对XiaoMi/MiuiBrowser、MQQBrowser等 UA 单独降级提示逻辑
SW 更新提示真正难的不是写几行 JS，而是让“检测→提示→激活→兜底”每个环节都可预测。最容易被忽略的是：用户看到提示时，新 SW 其实还没开始处理任何请求，它只是躺在那里等被唤醒——这个时间差，决定了白屏还是丝滑。
