web storage 同步需前端主动设计规则：以服务端为唯一数据源，先写服务端再更新 localstorage；读取时分两步（本地渲染+服务端校验）；跨标签页用 storage 事件通知；结构化存储需封装 json 安全读写与失效控制。
Web Storage 本身不自动同步，所谓“同步”是靠前端主动设计的读写规则来实现的。关键不是存到 localStorage 就完事，而是明确谁说了算、什么时候更新、怎么通知其他页面、以及出错时如何兜底。
以服务端为唯一数据源
所有业务状态变更必须走“先写服务端、再更新本地”的顺序。比如用户修改昵称：
- 调用 API 提交新昵称，等待后端返回成功响应（HTTP 200）
- 收到响应后，再执行
localStorage.setItem('user_profile', JSON.stringify(newData)) - 禁止“先改 localStorage 再发请求”，否则接口失败会导致界面显示已更新但实际未生效
- 推荐用
removeItem()清空旧键，而非尝试 merge 数据，避免字段残留或覆盖遗漏
读取时做轻量校验
页面加载后不要直接信任 localStorage 的值，而是分两步走：
- 立即读取本地数据渲染 UI（提升首屏体验）
- 紧接着发起一个带校验参数的请求，例如：
— 请求头加If-None-Match: "abc123"（ETag）
— 或 URL 带?_v=17429883（服务端返回的版本号） - 若服务端返回 304 或 “未变更”，维持当前状态；否则用新数据更新 localStorage 并刷新视图
- 对余额、订单状态等关键字段，跳过缓存直接回源，不依赖本地值
跨标签页状态通知靠 storage 事件
同源下多个标签页共享 localStorage，但 storage 事件只在“其他页”触发，当前页修改不会通知自己：
- 所有页面需提前注册
window.addEventListener('storage', handler) - 写入时建议用专用键名并附带语义，例如：
localStorage.setItem('sync_event', JSON.stringify({type: 'user_logout', ts: Date.now()})) - 监听方解析
type字段决定动作：是清空 token、重拉用户信息，还是忽略 - 注意：App、小程序等非浏览器环境无法监听该事件，需配合 version 字段 + 后端轮询兜底
结构化存储与失效控制
localStorage 只存字符串，但业务数据多为对象，需封装安全读写逻辑：
- 统一用
JSON.stringify / JSON.parse处理对象，捕获异常并降级（如返回空对象） - 值中嵌入
timestamp或version字段，读取时判断是否过期 - 敏感信息（如短期 token）设 TTL，启动时扫描清理陈旧项（如 7 天未更新的键）
- 结构升级时，旧版本数据可设 fallback 默认值，避免因字段缺失导致组件崩溃
