Web Storage需开发者主动设计同步机制，多标签页通过storage事件联动但当前页不触发自身变更；读取应本地优先并校验时效性，写入须以后端成功为前提；跨设备需结合version字段与增量同步接口。
Web Storage 本身不自动同步，同步更新必须由开发者主动设计和控制。关键不在“存”，而在“何时读、如何写、怎么通知、怎么兜底”。
多标签页间靠 storage 事件联动
localStorage 在同源下共享，但修改只触发其他页面的 storage 事件，当前页不会收到自身变更的通知。
- 所有页面需提前注册
window.addEventListener('storage', handler)，且 handler 中要判断event.key是否相关 - 仅调用
setItem()、removeItem()或clear()才触发事件；直接赋值（如localStorage.x = 'y'）无效 - 事件对象只含
key、oldValue、newValue、url和storageArea，不含业务含义，建议存结构化数据并加 type 字段，例如：localStorage.setItem('sync', JSON.stringify({type: 'cart_update', data: [...], ts: Date.now()}))
读取时：本地优先 + 主动校验
不能把 localStorage 当作权威数据源，尤其对时效敏感的内容。
- 页面加载时先读 localStorage 渲染界面，提升首屏体验
- 立即发起轻量接口请求（如带
If-None-Match、_v=时间戳或last_modified参数），验证是否过期 - 服务端返回 304 或 “未变更”则保留本地状态；返回新数据则更新 localStorage 并刷新视图
- 余额、订单状态等关键字段应跳过缓存，直连后端获取最新值
写入时：以后端为准，localStorage 仅为副本
所有状态变更必须以服务端成功响应为前提，再更新本地存储。
- 推荐策略：API 调用成功后，再执行
localStorage.setItem(key, newData)或localStorage.removeItem(key) - 避免“先删缓存再改库”，否则数据库失败会导致缓存丢失、大量请求打穿后端
- 对聚合类或计算结果，更稳妥的做法是删除对应 key，下次读取时重新生成并写入，降低写逻辑耦合度
跨设备/多端协同需叠加机制
storage 事件仅限同源浏览器标签页，App、小程序、其他设备无法监听，必须引入额外同步维度。
- 在 localStorage 中维护一个全局 version 字段（如服务器返回的
last_modified时间戳或业务版本号） - 各端监听 storage 事件，发现 version 变化，就调用
GET /sync?since=xxx拉取增量更新 - 后端需提供幂等的增量同步接口，并支持按 version 或时间范围过滤变更
- 客户端可结合定时检查（如登录/退出/页面可见时）+ 事件驱动，平衡实时性与资源消耗
