17370845950

sessionStorage是浏览器提供的、仅在当前标签页会话生命周期内有效的本地存储机制；关闭标签页即清空数据，刷新或恢复页面仍保留，且各同源标签页间完全隔离。

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”，而是为特定交互模式设计的：

• 多步骤表单（比如注册流程分 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 是钉在墙上的“白板”，擦了才没，不擦永远在。