localStorage需配合storage事件与响应式代理实现多标签页状态共享，核心是封装读写逻辑、监听变更并同步ref，而非直接操作；用作信号协调（如登出、全屏）比镜像状态更健壮，须加降级、错误处理与清理机制。
localStorage 本身不主动同步状态，但配合 storage 事件和合理封装，能实现稳定、可控的多标签页状态共享。关键不在“存”，而在“怎么听、怎么转、怎么用”。
用响应式代理桥接 localStorage 和 Vue/React 状态
直接在 watchEffect 或 useEffect 里读 localStorage 不会响应变化——它不是响应式源。正确做法是把 localStorage 封装成一个可被框架追踪的代理：
- 定义一个 ref（如 themeRef）承载当前值，并初始化为 localStorage.getItem('theme') || 'light'
- 所有写操作都走统一 setTheme 方法：先更新 ref，再调用 localStorage.setItem，保证视图与存储一致
- 全局监听 storage 事件，当 key 匹配时，重新从 localStorage 读取并赋值给 ref，触发组件重渲染
- 这样 watchEffect 就能真正“看到”变化，而不是只执行一次
模拟 sessionStorage 跨标签页同步
sessionStorage 天然隔离，但业务常需“新标签页自动登录”。可用 localStorage 做协调信道，实现伪共享：
- 新标签页打开时，检查 sessionStorage 是否为空；若空，写入 localStorage.setItem('getSessionStorage', Date.now()) 发起请求
- 已有标签页监听到该 key，立即把自身 sessionStorage 全量序列化后写入 localStorage.setItem('sessionStorage', JSON.stringify(...))
- 新标签页监听 'sessionStorage' 变更，解析后逐项写回自己的 sessionStorage
- 注意加防抖和超时机制，避免多个旧标签页同时响应造成冲突
做“信号”而非“状态镜像”
别把 localStorage 当数据库同步字段，而应把它当敲门声——尤其对全屏、编辑锁、登出等瞬态操作：
- 用户点击登出，调用 localStorage.setItem('logoutSignal', Date.now())，不存用户数据
- 其他标签页收到 storage 事件后，不直接跳转，而是先检查自身登录态（比如调用 /api/check-login），再决定是否刷新或跳转
- 全屏切换时写入 'fullscreenHint' + 时间戳，其他页收到后查 document.fullscreenElement，按需提示而非强制操作
- 这样既避开跨页状态不一致风险，又保留用户自主控制权
健壮性增强要点
生产环境不能只靠 localStorage.setItem 一写了之：
- 每次读写前检测 localStorage 是否可用（Safari 无痕模式下可能抛错），失败时降级为内存变量 + 提示
- 写入前用 JSON.stringify，读取后用 JSON.parse，但要包 try/catch —— 某些旧数据可能已损坏
- 定期清理临时键（如 'logoutSignal'、'getSessionStorage'），避免残留键干扰后续逻辑
- 同源判断要严格：协议、域名、端口三者完全一致才算同源，子域名 a.example.com 和 b.example.com 互不可见
