Web Storage是离线应用中专注用户状态与轻量数据的轻量级存储层，不参与资源缓存或网络拦截，仅存键值对字符串；localStorage跨会话持久保存偏好设置等，sessionStorage管理单页临时状态如表单进度，需配合Service Worker实现“页面可打开、操作可继续、数据不丢失”。
Web Storage 是离线应用中最基础、最轻量的客户端存储层，不负责资源缓存或网络拦截，而是专注保存用户状态、配置和结构简单的小数据。它不能替代 Service Worker 或 IndexedDB，但在快速读写、低延迟、零依赖的场景中不可替代。
Web Storage 的定位：状态层，不是缓存层
离线应用通常分三层：资源缓存层（Service Worker）、结构化数据层（IndexedDB）、轻量状态层（Web Storage）。localStorage 和 sessionStorage 属于最后一层——它们不缓存 HTML/CSS/JS 文件，也不处理网络请求，只存键值对字符串。比如用户选的主题色、最近搜索词、表单草稿、开关状态等。
- localStorage 适合跨会话保留的数据，如“夜间模式开启”、“默认语言”
- sessionStorage 更适合单页内临时状态，如多步骤表单的中间进度、未提交的编辑内容
- 它不参与 Service Worker 的 fetch 拦截流程，也不触发更新通知，纯粹同步、阻塞、轻量
与 Service Worker 协同工作的典型模式
Service Worker 负责把页面资源（HTML、API 响应等）缓存到 Cache API，而 Web Storage 则保存用户主动产生的状态。两者互补但不耦合：
- 用户离线时，Service Worker 返回已缓存的页面骨架，Web Storage 立即还原本地偏好设置（如字体大小、主题），无需等待任何异步操作
- 表单提交失败后，可将数据暂存 localStorage，待网络恢复再由后台任务或定时器触发重发
- 避免在 Service Worker 中直接读写 localStorage（它无法访问 DOM 和 Storage API），状态同步应由主页面完成
实际落地中的关键注意事项
看似简单，但容易因细节导致离线体验断裂：
- 容量限制必须预判：5–10MB 是理论值，不同浏览器、不同设备可能更低；超过会静默失败（setItem 抛错但不提示），建议用 try/catch 包裹并降级处理
- 字符串强制转换易出错：存对象必须 JSON.stringify()，取值必须 JSON.parse()，否则拿到的是 "[object Object]"；推荐封装 setJSON / getJSON 工具函数
- 同源隔离严格：http://a.com 和 https://a.com 不共享 storage；localhost:3000 和 localhost:8080 也不互通；开发时注意协议、端口、子域一致性
- 无事件监听机制：storage 事件只在其他同源 tab 中触发，当前页修改不会收到自己的变更通知；如需响应式更新，需配合 customEvent 或状态管理库手动派发
何时该换用 IndexedDB？
当出现以下任一情况，说明 Web Storage 已超出能力边界：
- 单条数据超过 1MB（如 base64 图片、长日志文本）
- 需要按字段查询、排序、分页（例如“查今天创建的待办事项”）
- 数据有明确关系模型（如用户→订单→商品）且需事务保障
- 预期总数据量超 20MB，或需长期积累历史记录
这时候 localStorage 就该让位给 IndexedDB——它支持索引、游标遍历和异步批量操作，是真正意义上的前端数据库。
