localStorage本身不自动同步，需通过setItem触发storage事件通知其他同源标签页，当前页修改不触发自身事件，且仅传递键值变化，无业务语义。
Web Storage（尤其是 localStorage）常被用来保存用户界面状态、会话标识或轻量级业务数据，但它本身不是缓存系统，也不具备自动同步能力。真正影响“状态同步”和“缓存一致性”的，是开发者如何设计读写逻辑、何时触发更新、以及多端/多标签页间如何协同。核心不在于存储本身，而在于控制权归属与更新节奏。
localStorage 是共享通道，不是自动同步器
同一源下的所有标签页共享 localStorage，但修改它不会自动广播给其他页面——只有 storage 事件会在**其他页面**触发。这意味着：
- 你必须主动调用
localStorage.setItem()才能发出信号，且值要变化（如写入时间戳），否则某些浏览器不触发事件 - storage 事件监听需在所有页面提前注册，且仅响应“他人写入”，当前页写入不触发自身事件
- 它只传递键名和旧/新值，不包含业务语义，需配合 version 字段或事件类型字段做区分（例如
localStorage.setItem('sync_event', JSON.stringify({type: 'user_logout', ts: Date.now()}))）
读取时：本地优先 + 主动校验，而非信任缓存
不能把 localStorage 当作权威数据源。正确做法是：
- 页面加载时先读 localStorage 渲染界面，提升首屏体验
- 立即发起轻量接口请求（如带
If-None-Match或_v=12345参数），验证本地数据是否仍有效 - 若服务端返回 304 或 “未变更”，保留本地状态；若返回新数据，则更新 localStorage 并刷新视图
- 对敏感操作（如余额、订单状态），跳过缓存直接回源，避免因 stale 数据引发误操作
写入时：以数据库为唯一源头，localStorage 仅作副本
所有状态变更必须先成功写入后端，再处理本地存储：
- 推荐策略：成功收到 API 响应后，调用
localStorage.removeItem(key)或setItem(key, newData)—— 删除更安全，避免双写失败导致不一致 - 禁用“先删缓存再改库”：万一数据库更新失败，缓存清空会导致大量请求直接打到 DB，还可能读到中间态快照
- 若需写入复杂计算结果（如聚合数据），建议删除缓存，等下次读取时再生成并写入，避免写逻辑耦合
多端协同：靠 version + storage 事件 + 后端兜底
单浏览器标签页内可依赖 storage 事件，但 App、小程序、其他设备无法监听。此时需叠加机制：
- 在 localStorage 中维护一个全局 version（如服务器返回的
last_modified时间戳或业务版本号） - 各端监听 storage 事件，发现 version 变化，就拉取增量变更（
GET /sync?since=1742988360）或全量刷新 - 后端提供强制同步接口，支持客户端主动上报本地 version 并获取差异数据
- 对关键状态（如登录态），每次页面激活（
visibilitychange）时做一次轻量心跳校验，防止长时间后台导致状态滞后
