sessionStorage和localStorage区别：存储时效对比

sessionStorage 数据仅在当前标签页或独立窗口中有效，关闭即清空，不跨标签共享；localStorage 数据持久保存，需手动清除，同源下所有标签页共享但需监听 storage 事件同步。

一句话概括：sessionStorage 的数据仅存活到标签页关闭；localStorage 一旦写入，只要不手动删除，就会永久保留。

sessionStorage：关闭标签页即清空，刷新不受影响

sessionStorage 的生命周期绑定在当前浏览上下文，即单个浏览器标签页或通过 window.open() 打开的独立窗口。在该标签页内，无论刷新页面、前进后退、还是用 location.reload() 强制刷新，已存储的数据都不会丢失。但一旦关闭该标签页，所有通过 sessionStorage.setItem() 保存的数据便会立刻消失，其他标签页也无法读取。

• 典型应用场景：适合存放表单草稿、多步流程的中间状态，例如电商结账时第二步填写的收货地址。
• 关键陷阱：通过 window.open() 新开的窗口拥有独立的 sessionStorage，与原窗口互不共享。
• 其他限制：不能跨域访问，不响应同域名下其他标签页的变更，本身无事件通知机制。

localStorage：关闭浏览器也不丢失，需手动清理

localStorage 的设计目标是持久化，生命周期与浏览器进程无关。即使关闭整个浏览器并重启电脑，下次打开同一网站时，localStorage.getItem(“theme”) 依然能取到值。其数据只会因三类操作而消失：调用 localStorage.removeItem()、localStorage.clear()，或用户在浏览器设置中清除该站点数据。

• 典型应用场景：存储用户长期偏好（如主题、语言）、长期有效的登录态 token（通常需配合更安全的 HttpOnly Cookie），或离线应用缓存的资源清单。
• 容量限制：每个源通常约 5–10 MB。超出配额时 setItem() 会抛出 QuotaExceededError 异常，已有数据不受影响。
• 共享与同步：同源下所有标签页共享同一份 localStorage 数据；但一个标签页修改后不自动更新其他标签页，需开发者主动监听 storage 事件实现手动同步。

核心误区：别把 sessionStorage 当作“临时 localStorage”使用

这是一个常见思维误区。有人认为“数据只用一会儿，用 sessionStorage 更安全”，结果用户意外关闭标签页后关键状态全失，应用却无恢复逻辑。实际上，两者的设计目的截然不同：

• sessionStorage 为单次会话隔离服务，不是“小一号的 localStorage”。
• 若数据需要跨标签页同步（如后台管理系统中多个页面共用筛选配置），必须使用 localStorage 并配合 storage 事件监听。
• 若数据较敏感（如短期 token），不能仅依赖前端存储——尽管 sessionStorage 数据不会随 HTTP 请求自动发送，但仍存在于内存中，一旦存在 XSS 漏洞，攻击者可直接读取。

最后，还有一个易忽视的共同点：这两个 Web Storage API 都只接受字符串作为值。若要存储对象，必须先调用 JSON.stringify() 序列化，读取时再用 JSON.parse() 反序列化。暗坑在于：如果对象包含函数、undefined、Date 实例或循环引用，JSON.stringify() 可能静默失败或丢失字段。这类问题在开发环境不易察觉，上线后则可能导致难以复现的数据错乱，排查十分棘手。