sessionStorage天然实现多标签页数据隔离，每个标签页拥有独立实例，互不读写；仅window.open()打开的新页会初始继承数据，其余方式均创建空实例。
sessionStorage 本身就是为多标签页会话数据隔离而设计的，不需要“实现”，只需要正确理解并直接使用它即可。它的隔离是浏览器原生行为，不是需要额外编码的功能。
sessionStorage 的天然隔离机制
每个标签页（或窗口）拥有完全独立的 sessionStorage 实例，互不读写、互不影响。这种隔离不依赖代码逻辑，而是由浏览器严格保障：
- 同域名下，A 标签页存
sessionStorage.setItem('token', 'abc')，B 标签页调用getItem('token')返回null - 刷新当前标签页，数据保留；关闭该标签页，数据立即清空
- 即使两个标签页都打开
https://example.com/dashboard，它们的 sessionStorage 仍是两份独立副本
哪些操作会触发数据复制？哪些不会？
只有特定方式打开的新标签页才会初始继承父页数据，但之后仍各自独立：
- ✅
window.open('./page.html')：新页加载时复制父页全部 sessionStorage（仅一次，后续修改不联动） - ❌ 地址栏输入 URL、右键“在新标签页中打开”、Ctrl+T 后粘贴访问：创建全新空实例，无任何数据
- ❌
<a href="..." target="_blank"></a>：等效于右键新开，不复制（注意：不是所有浏览器都支持此行为，但主流均已遵循规范）
适合用 sessionStorage 隔离的典型场景
当你明确需要“本页专用、关掉即丢”的状态时，sessionStorage 是最自然的选择：
- 表单草稿：用户填写一半关闭标签页，再次打开同页面时自动清空草稿，避免误提交旧内容
- 向导步骤：多步流程中记录当前 step，换标签页重新进入就从第一步开始，符合用户预期
- 临时筛选状态：列表页设置的排序/分页参数只影响当前浏览上下文，不干扰其他标签页的操作
- 防重复提交标记：提交成功后存一个标识，防止用户刷新页面重复触发请求
不该用 sessionStorage 却误用的常见误区
试图让它承担跨标签页共享职责，反而破坏了隔离性初衷：
- 把 token 存 sessionStorage 后发现新标签页要重新登录——这不是 bug，是设计如此
- 监听 storage 事件想同步 sessionStorage 变更——无效，它不触发 storage 事件
- 用它保存用户偏好设置（如主题、语言）——这类数据应跨标签页一致，该用 localStorage
真正需要隔离，就放心交给 sessionStorage；需要共享，就换 localStorage 搭配 storage 事件。两者分工明确，用对地方比“改造”它更可靠。
