sessionStorage 仅限单个 Tab 使用，关闭即清空，不支持跨 Tab 共享；需跨 Tab 同步时应使用 localStorage 配合 storage 事件，并按会话、用户、页面三级分类管理状态。
sessionStorage 本身不设计用于跨 Tab 共享，它的“隔离性”不是 bug，而是关键特性。所谓“数据冲突”，往往源于误把它当成了跨页状态同步工具。真正要解决的，不是让 sessionStorage 共享，而是明确各存储机制的职责边界，并用对地方。
理解 sessionStorage 的真实作用域
它只属于当前顶级浏览上下文（即一个 Tab 或独立窗口），关闭该 Tab 即清空。这种隔离能天然避免多任务串扰——比如你在 Tab A 填一半表单、Tab B 切换账号，彼此互不影响。但这也意味着：不能靠它维持登录态、不能指望刷新后自动恢复、也不能期待新开 Tab 继承旧数据。
- 同源下，每个 Tab 都有自己完全独立的 sessionStorage 实例
- 通过
window.open()或<a target="_blank">打开的页面，会复制父 Tab 的 sessionStorage 数据（仅初始拷贝，之后各自独立） - 手动新建 Tab 并输入 URL，或从书签打开，会创建全新、空的 sessionStorage
用 localStorage + storage 事件做轻量级跨 Tab 同步
当需要多个 Tab 共享基础状态（如登录 token、用户偏好、主题模式），localStorage 是更合适的选择，再配合 storage 事件实现响应式更新。
- 所有 Tab 写入同一 key（如
token）时，其他 Tab 会收到storage事件通知 - 监听事件后，主动更新本地 Vuex/Pinia 状态或重新初始化业务逻辑，而不是直接读取 localStorage
- 注意：
storage事件不会在触发修改的 Tab 自身触发，只通知其他 Tab
区分“会话状态”与“持久状态”，分层管理
把状态按生命周期和共享范围分类，是避免冲突的根本方法：
- 会话内临时数据（如表单草稿、未提交筛选条件）→ 存 sessionStorage，不跨 Tab，关页即丢
- 用户级持久数据（如登录凭证、语言设置）→ 存 localStorage，并用事件驱动各 Tab 主动同步
- 页面级瞬时状态（如折叠面板展开状态、滚动位置）→ 可存 URL 参数或用内存变量，避免污染存储
警惕 WebView 和浏览器兼容性差异
在混合应用或嵌入式 WebView 场景中，sessionStorage 行为可能偏离标准：某些 Android WebView 实现会让多个 Tab 共享同一份 sessionStorage，而 iOS WKWebView 更接近桌面 Chrome。若项目需兼容 WebView，不要依赖 sessionStorage 的隔离性，统一用 localStorage + 显式命名空间（如加 Tab ID 前缀）来模拟隔离。
