Store 过期策略

Store 库内置数据过期机制，用于管理验证码、临时票据、限时缓存等带时效性的数据。

设置过期

set 的第 4 个参数为过期秒数，0（默认）表示永不过期：

// 10 秒后过期
store.set('captcha', '123456', false, 10)

// 30 分钟后过期的持久化数据
store.set('accessToken', token, true, 1800)

// 不传 expire，永不过期
store.set('userName', 'Aaron', true)

过期时间点 = 写入时刻 + expire × 1000 毫秒，写入后不可修改；如需调整，重新 set 写入新的过期时间即可。

惰性删除

过期判断采用惰性删除策略：库内不设任何定时器，仅在以下时机检查并清理过期键：

• 访问该键时（get / has）
• 遍历键名时（keys / size）
• 存储库初始化时（一次性清理全部过期项）

因此：

• 已过期的键在被访问前仍存在于内存中，但访问时会被清理并视为不存在；
• get 对过期键返回默认值（无默认值时为 null），has 返回 false；
• 该策略无定时器开销，适合数据量小、偶发访问的轻量状态库。

初始化清理

每次应用启动、StoreLib 实例被创建时，会先恢复持久化数据，再遍历过期列表，将已过期的键（含其持久化对应条目）一次性清除，避免过期数据在启动后被残留读取。

重新写入清除过期

对存在过期记录的键执行 set 且不带 expire 时，旧的过期记录会被自动清除，该键恢复为永不过期：

store.set('captcha', '123456', false, 10)
store.set('captcha', '234567') // 清除过期记录，此后永不过期

只有显式传入 expire > 0 才重新建立过期记录。

持久化与过期组合

lasting 与 expire 相互独立，可自由组合：

lasting	expire	行为
false	0	仅内存，不持久化、不过期
true	0	持久化，重启后恢复
false	> 0	仅内存，存活期内可读
true	> 0	持久化且有过期时间；重启后若仍在存活期内则恢复，否则清除

持久化 + 过期时，过期列表同样会随实例持久化保存，重启后过期判断依然生效。

注意事项

• 过期的清理只发生在库的访问路径上（惰性），不要依赖「立刻消失」：读取前即使已过期，也需通过 get / has / keys 等 API 才会触发清除。
• 过期时间不随系统时间校准；与所有本地存储一致，清理精度受应用运行生命周期影响。
• 请通过 Store 库 API 读写数据；绕过库直接操作底层 storage 键不会建立/清除过期记录。