sessionStorage 是浏览器原生的前端会话级存储，生命周期仅限单个标签页从打开到关闭，同源其他标签页完全隔离，不参与网络请求，适用于临时、非共享、非持久化数据场景。

sessionStorage 就是浏览器原生实现的“前端会话级存储”，它的生命周期和作用域完全由当前标签页的会话（session）决定——关掉这个标签页，数据立刻清空，且其他标签页哪怕同源也完全不可见。

为什么叫“session”Storage？看它怎么响应浏览器会话行为

这里的 “session” 不是指后端的 session（服务器端会话），也不是 cookie 中那种基于进程的会话 Cookie，而是浏览器对「单个标签页从打开到关闭」这一完整生命周期的定义。它不依赖任何服务端逻辑，纯前端自治。

• 新开一个标签页访问 https://example.com/a.html → 创建独立的 sessionStorage 实例
• 在该标签页内跳转到 /b.html 或刷新页面 → sessionStorage 数据完好保留
• 右键「在新标签页中打开链接」→ 新建标签页拥有**全新、隔离**的 sessionStorage，旧数据不可读
• 直接关闭该标签页 → 整个 sessionStorage 对象被浏览器自动销毁，不留痕迹

和后端 session、会话 Cookie 的关键区别在哪？

名字相似，但机制和作用域完全不同，混用会导致状态丢失或安全错觉：

• sessionStorage：只属于当前标签页，不发请求，不跨页，不跨进程，不参与鉴权
• 会话 Cookie（未设 Expires）：属于整个浏览器进程，所有同源标签页共享，且每次 HTTP 请求都会自动带上 Cookie 头
• 后端 session：靠服务端生成 ID（常存于会话 Cookie 中）来关联用户状态，sessionStorage 里存的 token 若没同步给请求头，后端根本收不到

常见错误：把登录后的 token 存进 sessionStorage，却忘了在 fetch 或 axios 请求拦截器中手动加 Authorization 头 → 接口全 401。

什么场景下必须用 sessionStorage？

适合那些「只在这一次浏览中临时存在、绝不希望泄漏到其他窗口、也不需要持久化」的数据：

• 多步骤表单的中间状态（比如地址页填完跳支付页，关掉标签页就该放弃）
• 页面内临时筛选条件（如商品列表按价格排序，刷新后还应保持，但换标签页就不该继承）
• 防重复提交的临时标记（sessionStorage.setItem('submitting', 'true')，提交成功后删掉）
• 调试用的临时开关（如 sessionStorage.setItem('debugMode', 'true')，关掉标签即失效）

注意：sessionStorage 无法监听自身变化触发重渲染（React/Vue 需手动 useEffect + window.addEventListener('storage')，但该事件**不会在本页触发**，仅响应其他同源页的修改）。

真正容易被忽略的一点：即使你用 history.pushState 或 router.replace 切换 SPA 路由，只要没脱离当前标签页，sessionStorage 就一直活着——它认的是「标签页」，不是「URL」或「组件实例」。