前端高频面试题：为什么 sessionStorage 在不同 Tab 页不共享？

这是一个非常经典的前端面试题，也是实际开发中容易产生误解的地方。

简单直接的回答是：这是由 W3C 标准明确设计的。sessionStorage 的设计初衷就是为了"隔离"，而不是"共享"。

以下是详细的深度解析，帮助你彻底理解其中的逻辑：

1. 核心定义：什么是"Session"？

在 sessionStorage 的语境下，"Session（会话）"的定义范围被严格限制在当前标签页（Tab）或当前窗口（Window）中。

LocalStorage 的范围： 同源（Same Origin） + 浏览器实例。只要域名一样，所有 Tab 共享数据。
SessionStorage 的范围： 同源 + 顶级浏览上下文（Top-level Browsing Context） 。即：一个 Tab 就是一个独立的 Session。

2. 设计目的：为了"多窗口并行操作"

你可能会觉得不共享很麻烦，但这种设计其实是为了解决一个痛点：防止多窗口之间的数据干扰。

举个场景例子：

假设你在一个订票网站上，同时打开了两个 Tab：

Tab A： 正在帮张三买去北京的票。
Tab B： 正在帮李四买去上海的票。

如果 sessionStorage 是跨 Tab 共享的：

你在 Tab A 选择了"北京"，存入 Storage。
你在 Tab B 选择了"上海"，数据被覆盖了。
回到 Tab A 点击提交，结果系统读取的是最新的"上海"，导致张三买错票。

因为有了 sessionStorage 的隔离特性：

Tab A 和 Tab B 拥有完全独立的存储空间，互不干扰。这使得用户可以在同一个网站上同时进行多个独立的业务流程，而不用担心状态串台。

3. 一个特殊的例外：复制标签页

虽然不同 Tab 不共享，但有一个特殊情况需要注意：

如果你通过 "右键 -> 复制标签页" 或者在脚本中使用 window.open() 打开同源页面：

新 Tab 会"拷贝"旧 Tab 的 sessionStorage 数据。
但是！ 这仅仅是拷贝（Copy） ，不是同步（Sync） 。
复制完成后，两个 Tab 的数据就断开了联系。你在新 Tab 修改数据，旧 Tab 不会变；反之亦然。

4. 如果我一定要跨 Tab 共享数据怎么办？

如果你现在的业务场景确实需要不同 Tab 之间同步数据（比如：在一个 Tab 登录，其他 Tab 自动更新登录状态），你应该使用以下方案替代 sessionStorage：

方案 A：LocalStorage + storage 事件

这是最常用的方案。localStorage 是跨 Tab 共享的。你可以监听 storage 事件来感知其他 Tab 的修改。

JavaScript 复制代码

// Tab A 修改数据
localStorage.setItem('token', '12345');

// Tab B 监听变化
window.addEventListener('storage', (event) => {
  if (event.key === 'token') {
    console.log('其他 Tab 修改了 Token，我也要更新状态！');
  }
});

方案 B：Broadcast Channel API

这是一个更现代、更优雅的 API，专门用于同源下的跨上下文通信（Tab、Iframe、Worker）。

JavaScript 复制代码

// Tab A
const channel = new BroadcastChannel('app_channel');
channel.postMessage('Hello Tab B');

// Tab B
const channel = new BroadcastChannel('app_channel');
channel.onmessage = (msg) => {
  console.log(msg.data); // 收到 'Hello Tab B'
};

方案 C：SharedWorker

使用 SharedWorker 创建一个可以在多个 Tab 间共享的后台线程，通过它来中转数据（比较重，不常用）。

总结

sessionStorage 不共享 ：是因为它的设计目的就是为了让不同 Tab 拥有独立的运行环境，防止数据冲突。
localStorage 共享 ：是因为它的设计目的是为了持久化存储整个网站的数据。

理解了这个设计哲学，你就知道在什么场景该选什么存储方案了。