sessionstorage 是前端配合服务端鉴权的轻量缓存层，仅暂存已验证的低敏感会话状态（如角色、开关、过期时间戳），须同步清理、校验时效、禁止存储敏感信息且不跨标签页。
sessionStorage 是处理一次性会话验证的合适选择，但它不是独立的验证方案，而是前端配合服务端鉴权的轻量缓存层。它不参与身份认证本身，只用于暂存当前标签页内已通过服务端验证后的权限状态，提升响应速度和交互体验。
适合存什么验证相关数据
只存服务端明确返回、且可公开或低敏感的会话标识：
- 用户角色类型，例如：
"role": "editor"或"role": "guest" - 功能开关标记，如
"canPublish": true，由登录后权限接口统一返回 - 临时令牌过期时间戳（非完整 token），如
"tokenExpireAt": 1735689200000，用于本地快速判断是否需重新鉴权 - 会话唯一标识（如 sessionKey），仅用于前端逻辑分流，不替代服务端 sessionID
关键操作必须同步清理或更新
验证状态变化时，sessionStorage 必须及时响应，否则会导致界面与真实权限脱节：
- 用户登出时调用
sessionStorage.clear()，或逐项removeItem()清理权限字段 - 角色切换（如从 editor 升为 admin）后，重新请求权限接口，并用新数据覆盖原有 key
- 监听服务端推送的强制登出事件（如 WebSocket 收到
{"type":"auth:logout"}），立即清空并跳转登录页
每次读取前做有效性校验
不能直接信任 sessionStorage 中的数据，必须在使用前检查其完整性与时效性：
- 用
try...catch包裹JSON.parse(sessionStorage.getItem('role'))，避免解析失败导致页面异常 - 读取
tokenExpireAt后，对比Date.now() > expireTime，过期则清除并触发重新登录流程 - 权限守卫逻辑（如按钮显隐、路由跳转）应前置校验：确认值存在、类型正确、未过期，再执行后续渲染或操作
注意标签页隔离带来的限制
sessionStorage 天然不跨标签页，这对一次性会话验证既是约束也是安全特性：
- 新开 Tab 登录后，原 Tab 的 sessionStorage 不会自动同步——这防止了权限误继承，但也意味着多页协作需额外设计
- 若需多页保持一致验证状态，应以服务端 Session + Cookie 为基础，前端各页各自调用 /auth/status 接口获取最新状态，再写入本页 sessionStorage
- 禁止用 sessionStorage 存储完整 JWT、密码、手机号等敏感字段；所有关键操作（如删除、支付）仍需服务端二次校验权限
