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。
立即学习“Java免费学习笔记（深入）”；
什么场景下必须用 sessionStorage？
适合那些「只在这一次浏览中临时存在、绝不希望泄漏到其他窗口、也不需要持久化」的数据：
- 多步骤表单的中间状态（比如地址页填完跳支付页，关掉标签页就该放弃）
- 页面内临时筛选条件（如商品列表按价格排序，刷新后还应保持，但换标签页就不该继承）
- 防重复提交的临时标记（
sessionStorage.setItem('submitting', 'true')，提交成功后删掉） - 调试用的临时开关（如
sessionStorage.setItem('debugMode', 'true')，关掉标签即失效）
注意：sessionStorage 无法监听自身变化触发重渲染（React/Vue 需手动 useEffect + window.addEventListener('storage')，但该事件**不会在本页触发**，仅响应其他同源页的修改）。
真正容易被忽略的一点：即使你用 history.pushState 或 router.replace 切换 SPA 路由，只要没脱离当前标签页，sessionStorage 就一直活着——它认的是「标签页」，不是「URL」或「组件实例」。
