PWA更新体验“丝滑”的关键是用户无感中断、状态不丢失、操作不重复，需协同Service Worker生命周期、缓存策略与提示节奏：延迟激活SW、版本化分层缓存、轻量上下文提示、失败降级与熔断机制。

PWA 的更新体验是否“丝滑”，关键不在技术多炫酷，而在于用户感知不到中断、不丢失状态、不重复操作——这背后是一套兼顾 Service Worker 生命周期、缓存策略与用户提示节奏的协同机制。

精准控制 Service Worker 更新时机

浏览器默认在每次页面加载时静默检查新 Service Worker，但立即激活可能破坏当前会话。最佳做法是延迟激活，等用户自然离开当前页再升级：

• 在 install 阶段调用 self.skipWaiting()（仅当确认新版本完全向后兼容）
• 更稳妥的方式：在 waiting 状态下监听 controllerchange 或主动触发 postMessage 通知前端，由 UI 引导用户“刷新以应用更新”
• 避免在单页应用路由切换时频繁注册 SW——确保 SW 注册逻辑只执行一次（如放在 DOMContentLoaded 后且加判重）

版本化缓存 + 增量更新资源

不要依赖 cache.addAll() 全量替换，而是按资源类型分缓存空间，并用版本前缀隔离：

DeepBI DHTML 页面生成器

生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur

下载

• 静态资源（JS/CSS/图片）走 Cache API，命名如 static-v2.3.1；HTML 和 API 响应走网络优先或 Stale-while-revalidate
• 构建时自动生成 manifest 或 version.json，让 SW 脚本读取当前期望版本号，只更新变更文件（配合 ETag 或 Last-Modified 判断）
• 旧缓存清理放在 activate 钩子中，遍历 keys() 删除非当前版本的 cacheName

用户可感知、可掌控的升级提示

强制刷新伤体验，完全静默又让用户困惑。折中方案是轻量级、上下文相关的提示：

• 检测到新 SW 等待激活时，在右下角弹一个 3 秒自动消失的 toast：“有新版本可用，点击刷新”
• 若用户正在表单填写中，延迟提示，等其提交或离开当前视图后再出现；也可在导航栏加一个小点徽标，点击展开升级选项
• 提供“稍后提醒”按钮，并用 localStorage 记录下次提示时间（如 2 小时后），避免高频打扰

降级兜底与错误熔断

SW 更新失败或资源加载异常时，不能让用户卡死在白屏或旧版功能里：

• 在 fetch 事件中捕获网络失败，fallback 到缓存中最新可用版本（而非直接报错）
• 为关键 JS bundle 设置加载超时（如 8s），超时后回退到上一稳定版本的缓存 URL
• 监控 SW 安装/激活失败率，服务端聚合日志；若某版本失败率突增，自动暂停该版本推送并触发回滚流程