Service Worker 离线体验的核心是分层缓存策略：安装时缓存带哈希的静态外壳资源，动态内容按更新频率采用网络优先或缓存优先策略，API/页面/图片分别返回结构化离线响应，并主动管理缓存生命周期与用户提示。
Service Worker 在离线时提供友好降级数据，核心是提前缓存关键资源 + 智能响应策略 + 合理的兜底内容。不是简单“缓存所有”，而是有层次地控制什么该缓存、什么时候用缓存、没缓存时怎么优雅展示。
缓存关键静态资源（Shell First）
应用外壳（HTML、CSS、JS、图标、字体）必须在安装阶段缓存，确保首次离线也能打开基础界面。避免缓存整个站点，只缓存构建产物中带哈希的稳定文件。
- 在
install事件中用cache.addAll()预加载 shell 资源 - HTML 文件建议单独处理（如用网络优先+缓存后备），避免因 HTML 变更导致旧 shell 加载失败
- 使用版本化缓存名（如
'my-app-v1.2'），升级时清理旧缓存
为动态内容设计分层缓存策略
API 数据、图片、文章正文等无法预知的内容，需按用途区分缓存行为：
- 用户生成内容或高频更新数据：采用 网络优先，失败时 fallback 到最近缓存 + 显示“数据可能已过期”提示
- 低频变动内容（如帮助文档、作者介绍）：用 缓存优先，定期后台更新（stale-while-revalidate），保证离线可用且逐步刷新
- 纯离线功能所需数据（如本地设置、草稿）：存在 IndexedDB，并在 Service Worker 中封装读取逻辑，兜底返回默认值或空状态
提供语义化离线体验（不只是“网络错误”）
直接返回 503 或空白页会打击用户信心。应在 fetch 事件中主动拦截失败请求，返回定制响应：
立即学习“前端免费学习笔记（深入）”；
- 对页面请求（
request.destination === 'document'），返回一个轻量级离线 HTML 页面，含品牌标识、简明说明和重试按钮 - 对 API 请求，返回结构一致的 JSON 响应，如
{ "status": "offline", "data": [], "message": "当前处于离线状态，显示最近缓存内容" }，前端据此渲染友好提示 - 对图片等资源，可缓存一张通用占位图（如
offline-placeholder.svg），避免破碎图标
主动管理缓存生命周期与用户预期
缓存不是一劳永逸。需让用户感知状态，同时避免缓存膨胀：
- 在页面中显示“已启用离线支持”提示，必要时提供手动“刷新离线内容”按钮（触发
skipWaiting()+ 强制更新缓存） - 监听
controllerchange事件，在新 Service Worker 激活后提醒用户“新版已就绪，刷新获取更新” - 定期清理过期缓存（如在
activate事件中遍历并删除旧版本缓存），防止占用过多存储
不复杂但容易忽略：离线体验好不好，取决于你是否把“用户此刻需要什么信息”放在缓存策略中心，而不是技术上能不能缓存。
