sessionstorage是浏览器提供的、仅在当前标签页会话生命周期内有效的本地存储机制；关闭标签页即清空数据，刷新或恢复页面仍保留，且各同源标签页间完全隔离。
sessionStorage 是浏览器提供的、仅在当前标签页会话生命周期内有效的本地存储机制；它和 localStorage 最核心的区别不是“能不能存”，而是“什么时候自动消失”——sessionStorage 关闭标签页就清空，localStorage 不关浏览器也不会丢。
sessionStorage 是什么：只属于这个 tab 的临时抽屉
它本质是一个 Storage 对象，挂载在 window.sessionStorage 上，用法和 localStorage 几乎一样（setItem/getItem/removeItem），但数据完全隔离：
- 新开一个同域名的标签页 → 它有自己独立的
sessionStorage，读不到你上一个 tab 存的东西 - 刷新页面、前进后退、恢复崩溃的 tab → 数据还在，因为会话没结束
- 关闭该标签页（哪怕只关一个）→ 所有内容立即被浏览器丢弃，不可恢复
- 不参与任何 HTTP 请求，不会像
Cookie那样自动发给服务器
sessionStorage.setItem('cartItems', JSON.stringify([{id: 1, qty: 2}]));
const cart = JSON.parse(sessionStorage.getItem('cartItems') || '[]');
// 页面刷新后仍可读取，但关掉这个 tab 后再打开，getItem 就返回 null
和 localStorage 的关键差异：不是容量或 API，而是作用域与生命周期
两者 API 完全一致、都只能存字符串、容量都约 5–10MB，真正要盯住的只有三点：
-
生命周期：
sessionStorage绑定「页面会话」（tab 级），localStorage绑定「域名+协议+端口」，跨 tab 共享且永久存在（除非手动clear()或用户清缓存） -
作用域隔离：两个同源 tab 中，
sessionStorage互不可见；而localStorage任意一个 tab 修改，其他同源 tab 可通过监听storage事件感知 -
典型误用场景：把登录态 token 存
sessionStorage并以为“关 tab 就安全了”——其实只要页面没关，XSS 攻击仍能直接读取；真要防窃取，应配合HttpOnly Cookie+ 内存变量
什么时候必须用 sessionStorage？别硬套“临时”这个词
它不是“小号 localStorage”，而是为特定交互模式设计的：
立即学习“Java免费学习笔记（深入）”；
- 多步骤表单（比如注册流程分 3 步），中间状态只应在当前 tab 持续，用户开新 tab 填另一份时不应互相污染
- SPA 中某个页面的 UI 展开/折叠状态（如侧边栏收起），不希望用户换 tab 再回来时状态错乱
- 调试用的临时标记（如
sessionStorage.setItem('debugMode', 'true')），避免影响其他窗口的正常测试 -
注意：不要用它存用户偏好（如主题色）——用户换 tab 就失效，体验断裂；这类该用
localStorage
容易踩的坑：看似安全，实则危险
开发者常因名字里有 “session” 就误以为它等价于服务端 session，但其实：
-
sessionStorage和服务端 session 完全无关，既不传sessionId，也不受服务端控制 - 它不能跨 iframe（即使同源），子 iframe 的
sessionStorage是独立的 - 浏览器崩溃未正常关闭 tab 时，部分浏览器（如旧版 Safari）可能丢失数据，
localStorage更可靠 - 调用
setItem存对象必须手动JSON.stringify，读取时必须JSON.parse，否则得到的是[object Object]字符串
真正要记住的只有一句：sessionStorage 是浏览器给每个 tab 发的“一次性便签本”，写完关本子就烧掉；localStorage 是钉在墙上的“白板”，擦了才没，不擦永远在。
