sessionstorage 无原生过期机制，仅在标签页关闭后清空；需手动封装带时间戳的读写逻辑，并结合 visibilitychange 事件与定时 fallback 实现精准时效控制。
SessionStorage 本身没有过期时间
浏览器原生的 sessionStorage 不支持设置过期时间，也不自动清除“过期”数据。它只在**当前标签页生命周期内有效**：页面关闭（包括刷新）后仍保留，但标签页完全关闭（或浏览器进程结束）后即清空。所谓“定时清除”“自动失效”，是业务层必须自己补足的能力。
常见错误现象：sessionStorage.getItem('token') 在用户长时间未操作后仍返回旧值，导致权限校验失效或接口报 401；后台已踢出用户，前端却还在用过期 token 发请求。
- 使用场景：登录态临时缓存、表单草稿、跨路由轻量状态传递
- 不能替代
localStorage或后端 session 做长期/安全存储 - 不兼容私密模式下某些浏览器的 sessionStorage 行为（如 Safari 可能提前清空）
手动实现带时间戳的 SessionStorage 封装
核心思路：写入时存时间戳，读取时比对当前时间与预设有效期（如 30 分钟），超时则视为无效并自动删除。
示例封装函数（ES6）：
立即学习“前端免费学习笔记（深入）”；
const TimedSessionStorage = {
set(key, value, expiresMinutes = 30) {
const item = {
data: value,
timestamp: Date.now(),
expires: expiresMinutes * 60 * 1000
};
sessionStorage.setItem(key, JSON.stringify(item));
},
get(key) {
const item = sessionStorage.getItem(key);
if (!item) return null;
try {
const parsed = JSON.parse(item);
if (Date.now() - parsed.timestamp > parsed.expires) {
sessionStorage.removeItem(key);
return null;
}
return parsed.data;
} catch {
sessionStorage.removeItem(key);
return null;
}
}
};- 参数差异：
expiresMinutes是每个 key 独立控制的，不是全局配置 - 注意 JSON 序列化限制：不能存函数、undefined、Date 对象等非纯数据
- 性能影响极小，但高频读写建议加防抖或节流（如用于实时草稿）
监听页面可见性变化触发清理
用户切走标签页再回来时，可能已过去很久，此时应主动检查关键数据是否过期。利用 document.visibilityState 和 visibilitychange 事件是最轻量的时机。
实操建议：
- 在页面初始化时绑定一次
document.addEventListener('visibilitychange', ...) - 仅检查高敏感项（如
auth_token、user_profile），避免遍历全部sessionStorage - 不要在
visibilitychange中执行重渲染或网络请求，只做状态判断和本地清理 - Safari 对该事件触发有延迟，需配合定时 fallback（如每 5 分钟
setInterval检查一次）
和 localStorage 混用时的边界问题
有人会把“长期登录态”放 localStorage，“短期操作态”放 sessionStorage，但两者混合使用容易忽略同步逻辑。比如用户登出时，只清了 sessionStorage，而 localStorage 的 token 还在。
- 登出操作必须显式清理所有相关 key：
sessionStorage.removeItem('temp_form')+localStorage.removeItem('auth_token') - 避免用
sessionStorage.clear()全局清空——可能误删其他模块依赖的临时数据 - 调试时注意：DevTools 的 Application → Storage 面板中，
sessionStorage列表在标签页关闭后即消失，无法回溯
真正难处理的不是怎么设过期，而是怎么让“过期判断”和“业务动作”对齐——比如支付页的倒计时、聊天页的消息未读状态、编辑器的自动保存间隔，各自需要的时效粒度都不同。一个封装函数撑不住所有场景，得按需拆解。
