离线策略

目标： 一个无网络也能加载并保持可用的应用，因为 Service Worker 为每类请求提供 正确的内容。并不存在单一的「离线模式」——离线是一组按请求做出的决定：何时信任缓存、 何时信任网络。

这建立在已注册的 Service Worker 之上；若还没有，请先做 入门。worker 的注册与更新模型见 Service Worker 生命周期参考。

按请求类型选择策略

不同请求在新鲜度与韧性之间想要不同的权衡：

请求类型	策略	原因
应用外壳（HTML、CSS、JS）	缓存优先 / 预缓存	即时加载；下次访问时更新。
API / 动态数据	网络优先，回退到缓存	在线时新鲜，离线时仍可用。
图片、字体	陈旧时重新验证（SWR）	快速绘制，后台刷新。
极少变化的资源	带版本的缓存优先	避免重新获取不可变文件。

步骤

1. 在 install 时预缓存应用外壳。 在 worker 的 install 事件中打开一个带版本的缓存， 加入每个视图都需要的核心 HTML/CSS/JS。这正是首屏离线可用的关键。

2. 在 fetch 中从缓存提供匹配请求。 拦截 fetch，按上表依据请求应用策略，并在 缓存与网络都未命中时优雅回退。拦截模型见 Service Worker 参考。

3. 在 activate 时给缓存版本化并清理。 用版本命名缓存，并在 activate 中删除旧版本， 使陈旧资源不会堆积。activate 何时运行见 生命周期参考。

4. 提供离线回退页。 对离线时未命中缓存的导航，返回一个友好的缓存回退页， 而非浏览器错误。

5. 在支持时用 Background Sync 延迟写入。 把失败的 POST 入队，待恢复连接后重放—— 但要当作渐进增强。先在 background-sync 兼容性数据中确认支持， 因为它并非处处可用。

6. 留意存储预算。 缓存计入来源的配额，回收时可能被驱逐。对必须存活的数据，见 存储持久化。

诚实地测试

在浏览器开发工具中切换离线（而非仅飞行模式）并重新加载。真正的离线测试是冷启动重新加载 已安装的应用，而非内存里已准备好一切的热标签页。

下一步

• 性能 —— 缓存策略与感知速度高度重叠。
• 存储参考 —— 配额、持久化，以及驱逐会带走什么。
• Service Worker 参考 —— 每一步背后的 API。

← 返回指南总览。