sessionStorage适用于仅当前页有效、有明确时效、不跨页共享的临时数据，如验证码状态、表单草稿、筛选条件、上传元信息和模态框标记；存取需手动序列化，键名应规范，须及时清理并配合服务端校验。
sessionStorage 是处理动态生成的临时性业务数据的天然选择——它不跨标签页、不持久化、刷新保留、关闭即清空，正好匹配“一次会话内有效”的业务逻辑。
适合存哪些动态临时数据
关键看数据是否满足三个特征：只在当前页流程中使用、有明确时效边界、不需要跨页共享。典型例子包括：
- 验证码状态：发送时间戳、倒计时剩余秒数、绑定手机号（如 verify:138****1234），避免重复点击和前端误判有效
- 表单草稿：用户填写一半跳转离开，返回时自动还原输入内容，尤其适用于多步表单或长文本编辑场景
- 临时筛选/排序条件：列表页设置分类、时间范围、排序方式后进入详情页，返回时仍保持原视图状态
- 上传预览元信息：客户端生成的文件唯一 ID、缩略图 URL、进度标识等，仅本页上传流程需要
- 模态框开关标记：防止用户连续点击多次弹出多个重叠弹窗，用键如 modal:confirm-leave 控制显隐
写入与读取必须手动序列化
sessionStorage 只接受字符串值，直接存对象会变成 [object Object]，导致读取失败。所有结构化数据都需显式转换：
- 存的时候用 JSON.stringify()：比如
sessionStorage.setItem('cartTemp', JSON.stringify(items)) - 取的时候用 JSON.parse()，并做好容错：比如
const data = JSON.parse(sessionStorage.getItem('cartTemp') || '[]') - 键名建议纯字母、数字、下划线，避免空格、斜杠、中文，减少兼容性风险
- 值为 null 或 undefined 时，会被转成字符串 "null" 或 "undefined"，不是删除操作，需主动判断
配合业务逻辑做同步更新与及时清理
不能只靠内存变量维护状态，要让 sessionStorage 成为单一可信源：
- 倒计时类数据（如验证码）：每秒更新 sessionStorage 中的 countdown 字段，页面刷新后可从中恢复剩余时间
- 完成动作后立即清理：提交成功、关闭弹窗、验证通过等节点，调用 sessionStorage.removeItem(key)，避免残留无效状态
- 异常情况兜底：在 beforeunload 事件中做一次清理非必需，因 sessionStorage 本身随标签页关闭自动销毁；但对关键状态（如未提交表单）可加轻量级确认提示
- 服务端校验不可省：sessionStorage 纯属前端体验优化，验证码是否过期、是否用过、次数限制等，必须由服务端独立验证
避开常见误用陷阱
看似简单，几个细节容易引发线上问题：
- 别和 localStorage 混用：把登录态存在 sessionStorage 里，关掉标签页就登出，是合理设计；但若误存到 localStorage，就可能造成“用户以为已登出，实际 token 还在”的安全疏漏
- 隐私模式下可能静默失效：Safari 和部分浏览器在无痕窗口中限制 storage API，建议所有写入操作包裹 try/catch
- 跨子域名不共享：app.example.com 存的数据，api.example.com 读不到，同源策略严格生效
- 没有监听机制：当前页修改 sessionStorage，不会触发 storage 事件——该事件只在其他同源窗口修改时广播，响应式更新需自行封装状态管理
