Web Storage 与 Service Worker 是互补关系：前者存用户数据（如草稿、偏好），后者缓存资源文件（如 HTML、JS）；需协同实现离线体验，避免混用或误用。
Web Storage（localStorage/sessionStorage）和离线存储机制（如已废弃的 AppCache，或现代的 Service Worker + CacheStorage）不是替代关系，而是互补分工：前者管“用户数据”，后者管“资源文件”。配合得当，才能实现真正可用的离线体验——页面能打开、操作能继续、数据不丢。
明确职责边界：什么该存 Web Storage，什么该走 Service Worker
Service Worker 的 CacheStorage 专用于缓存 HTTP 请求/响应对，比如 HTML 页面、CSS、JS、图片等静态资源。它由浏览器在独立线程管理，支持版本控制、原子安装与策略化更新。
Web Storage 则运行在主线程，适合存小体积、字符串化的用户态数据，例如：
- 表单草稿（未提交的文本、选择项）
- 界面偏好（主题、语言、字体大小）
- 临时状态（当前筛选条件、分页位置）
- 轻量登录凭证（仅用于 UI 展示，如“已登录”标识）
注意：不要用 localStorage 存大量结构化数据（如整张用户列表），应改用 IndexedDB；也不要让 Service Worker 直接读写 localStorage——它无法访问主线程的 DOM 或 Storage API。
页面中实时同步用户输入与本地落盘
用户编辑内容时，必须“即时保存”到 localStorage，避免刷新或意外关闭导致丢失：
- 监听 input、change 等事件，每次变更立即调用
localStorage.setItem(key, value) - 页面加载时，用
localStorage.getItem(key)恢复内容并填入对应字段 - 可搭配防抖（debounce）减少频繁写入，但关键操作（如草稿）建议无延迟落盘
示例：一个笔记输入框可在用户打字时自动保存草稿，刷新后自动还原。
Service Worker 拦截失败请求，触发本地暂存逻辑
当用户发起网络请求（如提交任务）却处于离线状态时，Service Worker 可捕获该请求，并通过 postMessage 通知主页面执行本地暂存：
- 在 sw.js 的 fetch 事件中识别 API 请求（如 URL 含
/api/） - 检测
navigator.onLine === false，则不发起 fetch，改用event.ports[0]?.postMessage({ type: 'offline-save', data: ... }) - 主页面监听 message 事件，收到后将待同步数据存入 localStorage 或 IndexedDB 队列
后续网络恢复时，再由页面或后台同步机制（如 Background Sync）尝试重发。
避免常见误用与兼容陷阱
AppCache 已被所有主流浏览器废弃，不应再使用；它的声明式配置、更新机制僵硬、调试困难，且无法与 Web Storage 协同设计。
Service Worker 要求 HTTPS（或 localhost），注册路径需在合法 scope 内；首次注册后需刷新页面才生效；缓存名建议带版本号（如 v2-main），并在 activate 阶段清理旧缓存。
Web Storage 是同步 API，大量写入可能阻塞主线程；若需存二进制或复杂对象，需手动序列化（JSON.stringify）；且无过期机制，需业务层自行管理有效期。
