localStorage与sessionStorage区别详解

localStorage 和 sessionStorage 虽同为浏览器端的客户端存储方案，却在生命周期、作用域和适用场景上截然不同：前者持久化存储、同源标签页共享，适合保存用户偏好或长期登录态；后者仅限当前标签页、关闭即销毁，专为表单草稿等临时状态而生——但二者均只支持字符串，需手动序列化与反序列化，且 localStorage 的跨页共享特性可能引发数据冲突，而 sessionStorage 则完全隔离却无法监听变更。选错一个，轻则数据意外丢失，重则多标签编辑时互相覆盖，真正考验的是对业务数据“存活时间”与“可见范围”的精准判断。

localStorage 和 sessionStorage 都能存字符串，但生命周期、作用域和适用场景完全不同——选错一个，就可能造成数据残留或意外丢失。

localStorage 会一直留着，除非手动删或用户清缓存

它把数据写在浏览器本地磁盘上，关闭标签页、重启浏览器甚至关机都不影响。适合存用户偏好（比如主题色、语言）、长期登录态标识（如 auth_token 的哈希片段）、离线缓存的静态配置。

• 调用 localStorage.setItem('key', 'value') 后，值会被自动转成字符串；读取时仍是字符串，需自行 JSON.parse()
• 容量通常为 5–10MB（各浏览器不同），超出会抛 QuotaExceededError
• 同源（协议+域名+端口）下所有标签页共享同一份数据，改一个，其他页立刻能 localStorage.getItem('key') 读到新值
• 不参与 HTTP 请求，不会被发到服务器

sessionStorage 只在当前标签页存活，关掉就清空

它的生命周期绑定在「页面会话」上：新开一个标签页或窗口，哪怕 URL 完全一样，也是独立的 sessionStorage；F5 刷新保留，但关掉该标签页后所有数据立即消失。

• 适合临时中转数据，比如表单草稿、多步流程中的中间状态（从第2步跳到第3步时暂存 step2_data）
• 同样只支持字符串，也要自己处理 JSON.stringify() / JSON.parse()
• 同源下不同标签页互不可见，不存在跨页污染问题
• 注意：页面通过 window.open() 打开的子窗口，如果同源，能继承父窗口的 sessionStorage；但通过链接点击打开的新标签页不能继承

它们都不能存函数、日期对象、undefined 或 Symbol

直接塞进去会变成 "[object Object]" 或 "undefined"，再取出来就废了。

• 必须用 JSON.stringify() 序列化后再存，且确保数据是纯 JSON 可序列化的结构（不含循环引用、正则、Map/Set 等）
• 时间对象建议存 date.getTime() 或 date.toISOString()，读取时再 new Date()
• 遇到 undefined 字段，提前过滤掉或转成 null，否则 JSON.stringify({a: undefined}) 得到的是 {}
• 别试图存 function，它在 JSON.stringify() 里直接被忽略

监听变化要用 storage 事件，但只在其他标签页触发

你在当前页调用 localStorage.setItem()，不会触发本页的 storage 事件——这是最容易踩的坑。

• 只有同源下的其他标签页修改了 storage，当前页才能监听到：window.addEventListener('storage', e => console.log(e.key, e.newValue))
• e.oldValue 是旧值（可能为 null），e.newValue 是新值，e.url 是发起修改的页面地址
• sessionStorage 不触发 storage 事件
• 如果需要本页响应变更，得自己封装 set 方法，在内部同步触发自定义事件

真正麻烦的不是语法，而是搞不清「这个数据到底该活多久」「会不会被别的页面悄悄改掉」——尤其在 SPA 多标签协作场景下，一个 localStorage 误用，可能让两个编辑页互相覆盖对方的未保存内容。

本篇关于《localStorage与sessionStorage区别详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！