sessionstorage 数据仅在当前标签页或独立窗口中有效，关闭即清空，不跨标签共享；localstorage 数据持久保存，需手动清除，同源下所有标签页共享但需监听 storage 事件同步。
sessionStorage 数据只活到标签页关闭；localStorage 一旦写入，不手动删就一直存在。
sessionStorage 关闭标签页就清空，连刷新都不影响
它绑定的是「当前浏览上下文」——具体来说是单个 tab 或 window.open 打开的独立窗口。刷新页面、前进后退、甚至执行 location.reload() 都不会丢失数据；但只要关掉这个 tab，所有 sessionStorage.setItem() 存的数据立刻消失，且其他 tab 完全读不到。
- 典型场景：表单草稿、多步流程的中间状态（比如电商结账第2步填的收货地址）
- 注意陷阱：用
window.open()新开窗口时，新窗口有自己独立的sessionStorage，和原窗口不共享 - 不能跨域访问，也不响应同域名下其他 tab 的变更，没有事件通知机制
localStorage 关闭浏览器也不丢，但得手动清理
localStorage 的生命周期和浏览器进程无关，哪怕你关掉整个 Chrome、重启电脑、再打开同一页面，localStorage.getItem("theme") 还在。它只受三类操作影响：调用 localStorage.removeItem()、localStorage.clear()，或用户主动在浏览器设置里清除站点数据。
- 典型场景：用户主题偏好、语言选择、长期登录态 token（需配合 HttpOnly cookie 使用）、离线缓存的静态资源清单
- 容量限制约 5–10 MB，超限时
setItem()会抛出QuotaExceededError异常，已有数据不受影响 - 同源下所有 tab 共享同一份数据，但修改不会自动触发其他 tab 的监听（需靠
storage事件手动监听）
别把 sessionStorage 当“临时 localStorage”来用
有人以为“反正只用一会儿，sessionStorage 更安全”，结果在用户意外关闭 tab 后丢失关键状态，又没做恢复逻辑。其实两者设计目的完全不同：
-
sessionStorage是为「单次会话隔离」服务的，不是“小一号 localStorage” - 如果数据需要跨 tab 同步（比如后台多个管理页共用一个筛选配置），必须用
localStorage+storage事件监听 - 如果数据敏感（如短期 token），别只依赖前端存储 ——
sessionStorage虽不随请求发送，但仍在内存中可被 XSS 直接读取
真正容易被忽略的是：两个 API 都只接受字符串值，存对象必须 JSON.stringify()，取的时候必须 JSON.parse()；一旦对象里有函数、undefined、Date 实例或循环引用，JSON.stringify() 就会静默失败或丢字段 —— 这类问题在线上很难复现，但一出就是数据错乱。
