sessionstorage与localstorage的本质差异在于设计目标：前者专注单标签页临时状态隔离，后者面向同源跨标签页持久共享；典型场景分别为表单草稿/多步流程与用户偏好/登录态同步。
sessionStorage 和 localStorage 的行为差异，本质不是“功能强弱”，而是设计目标不同：前者专注单页会话内的临时状态隔离，后者面向同源下跨标签页的持久数据共享。理解这个出发点，才能准确匹配场景。
sessionStorage 的典型隔离场景
它天然适用于“不希望被其他窗口干扰”的瞬时上下文：
- 表单草稿暂存：用户在填写长表单时刷新页面，数据仍保留；但若另开一个相同页面的标签页，不应自动带入前一页面的输入内容
- 多步骤向导的状态管理：每一步的中间结果存在 sessionStorage 中，关闭当前标签页即清空流程，避免残留状态影响新会话
- iframe 内部独立会话：嵌入的子页面（如第三方组件）使用 sessionStorage 存储自身 UI 状态，与父页完全解耦，互不污染
- 敏感操作的一次性凭证：例如支付确认页临时存一个 token，仅本页有效，新开窗口或复制链接打开后失效
localStorage 的典型共享场景
它适合需要“一次写入、多处可见”的同源持久数据：
- 用户偏好设置同步：暗黑模式、语言选择、字体大小等，在任意同源标签页中修改后，其他已打开的标签页可通过 storage 事件实时响应
- 登录态标识（配合服务端）：将 token 存入 localStorage，多个标签页均可读取并携带至接口；注意需搭配合理的过期校验与登出清理逻辑
- 离线缓存资源索引：如 PWA 应用缓存的文件列表、版本号等元信息，所有标签页共用同一份缓存控制策略
- 跨标签页协作信号：用 localStorage.setItem 触发 storage 事件，通知其他标签页执行刷新、重连或退出操作
容易混淆的边界情况
有些行为看似反直觉，实则有明确规则：
- window.open() 打开的新窗口：即使同源，sessionStorage 不继承也不共享；localStorage 可读可写，但属于同一存储空间——修改会触发 storage 事件
- 隐私/无痕模式：localStorage 数据在会话结束时清除；sessionStorage 表现一致，但部分浏览器可能提前限制写入
- WebView 环境：Android/iOS 原生 WebView 对 sessionStorage 的处理更宽松，常表现为多标签页共享，这与标准浏览器不同，需单独适配
- iframe 同源嵌套：父页与 iframe 各自拥有独立的 sessionStorage 和 localStorage 实例，不能直接访问对方；通信需通过 postMessage
选型判断口诀
面对存储需求，可快速对照：
- 关掉这个标签页，数据还该不该留？→ 留：localStorage；不留：sessionStorage
- 另一个同源标签页打开，要不要立刻看到变化？→ 要：localStorage + storage 事件；不要：sessionStorage
- 数据是否只服务于当前操作流，且与其他窗口绝对无关？→ 是：sessionStorage；否：考虑 localStorage 或服务端 session
