sessionStorage本身不管理历史栈，仅在当前标签页会话中暂存轻量上下文数据（如表单草稿、搜索条件、滚动位置），需配合history API的pushState/popstate实现导航状态同步与返回拦截。
sessionStorage 本身不管理历史访问栈，浏览器的 history API（如 pushState、popstate）才负责 URL 和导航状态的同步。sessionStorage 的作用是**在当前标签页会话内暂存与路由相关的轻量上下文数据**，它和 history 协作，但不能替代 history。
sessionStorage 存什么才合理
它适合保存那些“只在本次页面生命周期内有效、且不随 URL 变化自动失效”的临时状态，比如：
- 表单草稿：用户在某个页面填写了一半的注册信息，跳转离开前存入 sessionStorage，返回时可恢复
- 搜索筛选条件：在商品列表页设置了价格区间和品牌，点击详情页后返回，用 sessionStorage 恢复筛选项
- 页面滚动位置：离开前记录
document.scrollingElement.scrollTop，popstate 触发后还原 - 临时身份标识：SPA 中未登录用户生成的访客 ID，仅限当前会话使用
怎么和 history 配合使用
关键不是“用 sessionStorage 替代 history”，而是“在 history 生命周期中注入额外状态”。典型做法是：
- 监听
popstate事件，在回调里从 sessionStorage 读取对应 key 的数据（如sessionStorage.getItem('searchFilters')），再更新组件状态 - 在路由跳转前（例如点击链接或调用
router.push），主动写入相关数据：sessionStorage.setItem('formDraft', JSON.stringify(draft)) - 避免把整个路由路径或 history.state 原样塞进 sessionStorage —— 这会造成冗余，history.state 本身已支持携带序列化数据
哪些情况不该用 sessionStorage 管历史
以下需求 sessionStorage 无法满足，必须依赖 history API 或路由库：
立即学习“前端免费学习笔记（深入）”；
- 用户点击浏览器后退/前进按钮时触发视图切换 → 由
popstate驱动，不是 sessionStorage - URL 改变但页面不刷新 → 必须用
pushState或replaceState - 跨标签页共享导航状态 → sessionStorage 是隔离的，此时应考虑 localStorage + storage 事件，或服务端会话
- 需要持久化保存（关掉标签页还想恢复）→ 应改用 localStorage
一个实用小技巧：用 key 命名模拟“栈帧”
可以按路由路径生成唯一 key，让不同页面的状态互不干扰：
const pathKey = `pageState_${location.pathname.replace(/\//g, '_')}`;
sessionStorage.setItem(pathKey, JSON.stringify({ scrollY: window.scrollY, filters: activeFilters }));
这样即使用户在 /list 和 /detail 之间反复跳转，各自的状态也能独立存取，不会覆盖。
