浏览器Storage API无原生过期机制，需手动实现：存时记录时间戳，取时判断时效并清理；支持惰性清理（读时检查）和定时主动清理，并可监听storage事件跨页同步状态。
浏览器 Storage API（如 localStorage 和 sessionStorage）本身不支持原生过期机制，所有数据默认永久保存（localStorage）或会话级有效（sessionStorage）。要实现“过期”，必须靠开发者主动设计逻辑。核心思路就两个：**存的时候记时间，取的时候判时效**，再配合清理策略。
手动封装带过期时间的 set/get 方法
这是最常用、最可控的方式。每次存数据时，把值和过期时间戳一起序列化；读取时先解析，再比对当前时间是否超限。
- 存储时写入
{ value, expiry }对象，并用JSON.stringify转为字符串 - 读取时反序列化，检查
expiry < Date.now()，过期则自动调用removeItem并返回null - 示例中 expiry 单位建议统一用毫秒（如
Date.now() + 1000 * 60 * 30表示30分钟），避免分钟/秒换算出错
惰性清理：读取时触发过期判断
不过期不删，只在真正访问某条数据时才检查并清理。适合低频访问或资源敏感场景。
- 优点是零额外开销，不占用定时器、不扫描全量数据
- 缺点是冷数据可能长期残留——比如用户从未再打开某个页面，对应缓存就一直占着空间
- 适用于登录态、临时配置、短期API响应等有明确生命周期的数据
主动定时清理：后台周期性扫描
用 setInterval 定期遍历所有 key，批量识别并移除过期项。适合对存储空间要求严格、或存在大量低频缓存的项目。
立即学习“Java免费学习笔记（深入）”；
- 建议限制单次清理数量（如每次最多删5条），防止阻塞主线程
- 可搭配 key 命名约定（如加前缀
cache_）缩小扫描范围 - 注意不要在页面卸载前（
beforeunload）启动新定时器，避免内存泄漏
监听 storage 变化做联动处理
当其他标签页或窗口修改了 localStorage，当前页可通过 storage 事件感知。可用于同步清理或刷新状态。
- 例如：用户在标签页A退出登录，删除
auth_token，标签页B监听到e.key === 'auth_token' && e.newValue === null就立即跳转登录页 - 该事件无法捕获自己页面发起的变更，仅响应其他上下文的改动
- 适合做跨标签页的状态协同，不是过期主逻辑，但能补足用户体验闭环
