localStorage不是真正离线存储，而是轻量易用的浏览器端持久化方案；需用try-catch处理QuotaExceededError等异常、JSON序列化非字符串值，并配合降级策略与手动同步机制提升可靠性。
localStorage 是离线应用中最基础、最易接入的本地存储方案，但它不是“开箱即用”的同步解决方案——它只负责存和取，不处理网络状态、冲突、重试或跨标签页一致性。真正可靠的离线体验，需要围绕 localStorage 构建一套有意识的数据同步策略。
localStorage 的定位与边界
它本质是浏览器提供的键值对持久化存储，数据保留在用户设备上，关闭页面甚至重启浏览器后依然存在（除非被清除或超出配额）。但要注意：
- 只能存字符串，对象必须 JSON.stringify() 后再写入，读取时必须 JSON.parse()
- 容量有限（通常 5–10 MB），超限时会静默失败或抛出 QuotaExceededError
- 无痕/隐私模式下可能被禁用，iOS Safari 在低内存时可能自动清理
- 操作是同步的，大体积数据写入会阻塞主线程，影响交互响应
- storage 事件只在其他同源标签页触发，当前页修改需手动通知自身逻辑
离线数据暂存的关键实践
用户填写表单、编辑配置、创建任务等操作，在断网时不能丢失。暂存环节要兼顾健壮性和用户体验：
- 用防抖（如 400ms 延迟）代替实时保存，避免频繁 I/O 和无效存入（如 placeholder 值）
- 为每类待同步数据设计唯一 key，例如 form-checkout-20260623-abc123，防止多页覆盖
- 存前校验字段有效性，跳过空值、默认选项等无意义变更
- 每次写入都包裹 try/catch，捕获 QuotaExceededError 等异常，并降级到 sessionStorage 或提示用户
- 表单提交时必须调用 event.preventDefault()，否则原生提交会刷新页面、中断 JS 同步逻辑
网络恢复后的可靠同步机制
仅靠 window.navigator.onLine 判断是否联网不可靠——它只反映物理连接，不保证服务可达。真实同步应基于“失败兜底 + 主动调度”：
- 页面加载后，尝试 fetch 一个轻量健康检查接口（如
/api/health），成功则立即触发待同步队列 - 注册 Background Sync：
navigator.serviceWorker.ready.then(sw => sw.sync.register('submit-pending')) - 在 Service Worker 中监听
sync事件，从 localStorage 读出待提交数据，逐条发起 fetch 请求 - 同步成功后调用
localStorage.removeItem(key)；失败则保留，并记录重试次数（如 { data: ..., retry: 2 }），避免无限重试 - 每次同步前先验证 localStorage 是否可用（
try { localStorage.getItem('test') }），不可用时切换至 sessionStorage 或内存缓存
进阶补充：与 IndexedDB 协同使用
当数据量大、结构复杂或需事务保障时（如遥测历史、离线消息队列），仅靠 localStorage 不够：
- 用 IndexedDB 存储主体数据（支持索引、批量、事务），localStorage 仅存轻量元信息（如最后同步时间、队列长度、用户偏好）
- Open MCT 等框架已将两者分层使用：LocalStorageObjectProvider 管理对象元数据，PersistencePlugin 基于 IndexedDB 处理遥测数据
- 同步时优先从 IndexedDB 读取完整数据块，localStorage 可作为快速状态快照（如“上次同步时间戳”）
