SessionStorage适合缓存单次会话内可复用、易失效、非敏感的权限中间结果，如角色标识、过期时间戳、响应状态码和初始化标志，但必须配合服务端鉴权与读写时的严格校验、同步更新机制。
SessionStorage 适合缓存单次会话内的权限校验中间结果，但不能替代服务端鉴权。它的价值在于减少重复请求、提升响应感知速度，并配合前端守卫做轻量级状态管理。
存储哪些中间结果更合理
只缓存可复用、易失效、非敏感的中间态，避免冗余和安全隐患：
- 当前角色标识（如 "admin"、"editor"），不存完整权限列表
- 角色获取时间与 token 过期时间戳（tokenExpireAt），用于时效性判断
- 最近一次权限接口的响应状态码或错误类型（如 "401"、"network_error"），辅助错误兜底逻辑
- 是否已完成初始化校验（isPermissionLoaded: true），防止组件重复触发请求
写入时机要精准及时
权限状态变化时必须同步更新 sessionStorage，否则会出现“界面显示 admin，实际已降权”这类不一致：
- 用户登出时调用 sessionStorage.clear() 或逐项 removeItem()
- 角色切换后，重新请求权限接口，成功后用新数据覆盖原有 key，例如：
sessionStorage.setItem('userRole', JSON.stringify({ role: 'viewer', expireAt: 1746594000000 })) - 监听自定义全局事件（如 auth:changed），在事件回调中刷新缓存
读取前必须做有效性校验
不能直接信任 sessionStorage 中的内容，每次使用前都要验证其可用性：
立即学习“前端免费学习笔记（深入）”；
- 用 try...catch 包裹 JSON.parse(sessionStorage.getItem('userRole'))，防解析失败崩溃
- 检查 expireAt 是否小于当前时间戳，过期则清空并跳转登录页
- 组件内做双重守卫：先确认 userRole 存在且未过期，再比对角色值，例如：
v-if="role && Date.now()
注意标签页隔离带来的限制
SessionStorage 不跨标签页共享，这对多窗口协作场景是关键约束：
- 新开 Tab 访问同一页面时，不会继承原标签页的权限缓存，需重新拉取
- 若需多页状态同步，应改用 localStorage + storage 事件 广播变更（但需规避 XSS 风险）
- 所有关键操作（如删除、支付、提交）仍须向服务端二次校验权限，前端缓存仅作展示优化
