浏览器存储、Service Worker 与离线能力
浏览器存储、Service Worker 与离线能力
这篇笔记还在编辑中，内容可能会继续补充、调整或重写。
先区分数据类型
浏览器提供的存储能力解决不同问题：
- Cookie 会随匹配请求发送，适合由服务端管理会话，但容量小且需要严格设置安全属性。
- Web Storage API 简单、同步执行，适合少量非敏感设置，不适合大型数据或高频读写。
- IndexedDB 是异步事务型数据库，适合结构化数据、离线队列和较大缓存。
- Cache Storage 存储 Request/Response，主要服务于网络响应缓存和 Service Worker。
客户端存储不可信，也不是永久存储。用户可以清除数据，浏览器会实施配额和回收策略，XSS 也可能读取脚本可访问的数据。
Service Worker 的位置
Service Worker 独立于页面运行，可以拦截作用域内的网络请求、处理缓存、推送和后台任务。它不是普通 Web Worker：不能直接访问 DOM，并具有安装、等待、激活和被终止后重启的生命周期。
更新时旧页面可能仍由旧 Worker 控制。贸然调用 skipWaiting() 和 clientsClaim() 可能让旧页面逻辑配上新缓存或新 API，造成版本不一致。更新策略必须包含用户提示、兼容窗口和失败恢复。
常见缓存策略
- Cache First：适合带内容哈希且不可变的静态资源。
- Network First：适合希望优先获取最新数据、离线时允许回退的页面或接口。
- Stale While Revalidate：先返回缓存并在后台更新，适合可接受短暂陈旧的内容。
- Network Only / Cache Only：用于明确禁止缓存或完全预缓存的特殊场景。
策略必须按资源类型设计，不能用一个规则覆盖 HTML、版本化资源和用户数据。认证响应、个人信息和写请求默认不应被无边界缓存。
离线写入
离线提交需要设计幂等键、重试退避、冲突解决、权限过期和用户可见状态。队列中的请求不能假设重新联网后仍然有效；登出时还要清理属于原会话的数据。
实践任务
- 为应用壳和带哈希资源配置预缓存。
- 为只读列表实现 Network First，并提供明确的离线提示。
- 发布两个不兼容版本，观察旧标签页和新 Service Worker 的组合。
- 使用浏览器离线模式、清除存储和配额限制验证恢复路径。
验收标准
- 能解释四种存储能力的安全、容量和同步模型差异
- HTML 与带哈希资源使用不同缓存策略
- Service Worker 更新不会静默破坏已打开页面
- 离线数据能区分待同步、失败和已确认状态
- 登出、权限变化和缓存清理都有明确处理