断网时业务仍可运行，依靠service worker（调度中枢）、cache api（资源级缓存）和indexeddb（结构化数据存储）协同实现可编排的离线流程：sw拦截请求并分层处理，cache api显式管理多版本缓存，indexeddb持久化用户操作并支持联网后同步。
断网时还能跑业务，靠的不是 Application Cache（早已被移除），而是 Service Worker + Cache API + IndexedDB 这套现代离线三件套。它不依赖浏览器自动缓存行为，而是由你主动定义哪些资源必须可用、哪些数据要持久保存、请求失败时如何兜底——这才是真正可编排的离线业务流。
Service Worker 是离线业务的调度中枢
它不是缓存工具，而是运行在浏览器后台的“离线代理”。一旦注册成功，就能拦截所有 fetch 请求，决定是返回缓存、发起网络请求、合成响应，还是直接返回预设页面（比如 /offline.html）。关键在于它的生命周期可控：
-
install 阶段：预缓存核心静态资源（HTML、CSS、JS、图标、兜底页），用
caches.open('v2.1')命名版本化缓存，确保更新不污染旧数据 -
activate 阶段：调用
caches.keys()扫描并删除非当前版本的缓存，避免冗余堆积 - fetch 阶段：按资源类型分流处理——导航请求走缓存优先，API 请求走网络优先并自动更新缓存
Cache API 负责资源级离线供给
它不像 HTTP 缓存那样受 header 控制，而是完全由代码显式管理。你可以为不同用途建多个缓存空间：
-
static-cache-v2：存 HTML/CSS/JS，用
cache.addAll()在 install 时批量写入 -
api-cache：存用户配置、列表数据等，用
cache.put(request, response.clone())在 fetch 后动态写入 -
fallback-cache：专门存
/offline.html和占位图，确保任何请求失败都有体面回退
注意：response.clone() 必须调用，否则响应体只能读一次，缓存和页面渲染会争抢流。
IndexedDB 承载结构化业务数据离线操作
当用户在断网时提交表单、编辑草稿、标记待办，这些状态不能丢。IndexedDB 提供事务性、异步、容量大的本地数据库：
- 建 objectStore 存用户行为日志，字段含
timestamp、action、payload - 联网后监听
navigator.onLine或用 Background Sync API 触发同步任务 - 同步失败时保留记录，下次重试；成功后标记为已提交并清理本地条目
离线业务流需分层设计策略
不能所有请求一视同仁。典型分层如下：
- 导航请求（GET /）：缓存优先 + fallback 页面，保证主界面始终可打开
- 静态资源（.css/.js/.png）：缓存优先，配合版本号强制更新，避免旧 JS 加载新 HTML 出错
- API 请求（POST /api/submit）：网络优先，失败时存入 IndexedDB，带时间戳和重试计数
- 搜索/过滤类请求：缓存结果 + 指示“数据可能过期”，允许用户手动刷新
这样编排后，断网不再意味着功能冻结，而是降级为“本地操作+延迟同步”的稳健流程。
