sessionstorage的核心价值是维持单次会话内数据连续性，适用于页面刷新、路由跳转等场景；需json序列化对象存储；应主动清理敏感数据；与localstorage本质区别在于生命周期绑定标签页而非域名。
sessionStorage 的核心价值在于它天然适配“单次会话内数据连续”的场景——页面刷新、路由跳转、甚至临时离开第三方链接再返回，只要标签页没关，数据就还在。它不是用来替代后端或做长期缓存的，而是解决“用户还没走，但页面已重载”时的状态断层问题。
适合用 sessionStorage 的典型场景
它最适合保存那些“只对当前操作流程有意义”的临时状态：
- 表单未提交前的输入内容（比如多步骤注册中第2步填的信息，刷新后不丢失）
- 列表页的筛选条件或分页参数（搜索后跳转详情页，返回时仍保持原筛选）
- 临时 token 或会话标识（如第三方授权回调后暂存 BizToken，供后续接口调用）
- 折叠/展开状态、选中项、临时标记（如表格中用户勾选的几行，切换 tab 后仍保留）
对象存储必须序列化
sessionStorage 只接受字符串作为 value。直接存对象会变成 [object Object]，取出来就废了。
正确做法是存前用 JSON.stringify()，取后用 JSON.parse()：
- 存：
sessionStorage.setItem('user', JSON.stringify({ id: 1, name: '张三' })) - 取：
const user = JSON.parse(sessionStorage.getItem('user') || '{}')（加|| '{}'防止 null 报错） - 注意：含函数、Date、RegExp、undefined 或循环引用的对象不能直接 JSON 序列化，需先清洗或改用其他方案
主动清理比依赖自动清除更可靠
虽然关闭标签页后 sessionStorage 会自动清空，但实际开发中常需提前干预：
- 用户登出时，应主动
sessionStorage.clear()或逐个removeItem()，避免残留敏感信息 - 页面卸载前（如监听
beforeunload）可做轻量清理，但不宜放耗时逻辑 - 不要假设“反正关掉就没了”，尤其涉及 token、权限标识等，显式清除才是安全习惯
和 localStorage 的关键区别要拎清
两者 API 一致，但语义和生命周期完全不同：
- sessionStorage：绑定到“浏览器标签页”，同域下新开标签页互不可见，关掉该页即销毁
- localStorage：绑定到“域名”，所有同域标签页共享，关闭浏览器也不消失，直到代码或用户手动清除
- 选错会导致：本该随页关闭的临时数据被意外保留（如测试环境 token 泄露），或该跨页复用的状态每次打开都重置（如用户主题偏好）
