uni.setStorageSync 本身不支持过期时间，需自行封装：写入时同步存值与对应 _deadtime 时间戳（单位秒），读取时比对当前时间判断是否过期，过期则返回默认值并可清理。
uni.setStorageSync 本身不支持过期时间，必须自己封装逻辑。核心思路是：缓存值 + 单独存一个过期时间戳（用 key 拼接后缀），读取时比对当前时间戳判断是否过期。
为什么不能直接用 uni.setStorage 或 uni.setStorageSync 设过期时间
uni.setStorage 或 uni.setStorageSync 设过期时间uni.setStorage 和 uni.setStorageSync 是纯存储接口，没有 expire、ttl 或类似参数。官方 API 文档明确说明：它只负责存/取，不管理生命周期。
- 异步版
uni.setStorage的OBJECT参数里没有过期字段 - 同步版
uni.setStorageSync更是只接受key和data两个参数 - 所有平台（微信小程序、App、H5、HarmonyOS Next）均一致，无例外
怎么封装一个带过期时间的 set / get
最轻量、跨端稳定的做法是：为每个 key 额外存一个 _deadtime 或 _expire 时间戳（单位：秒），读取时做判断。
- 写入时：
uni.setStorageSync(key, value)+uni.setStorageSync(key + '_deadtime', timestamp) - 读取时：先取
uni.getStorageSync(key + '_deadtime')，再和Date.now() / 1000比较 - 过期就返回默认值（或
undefined），并建议调用uni.removeStorageSync(key)清理脏数据（但不是必须立刻删）
示例（精简版）：
Date.parse(new Date())
-
别用
Date.parse(new Date())：它在某些环境下返回NaN，应统一用Date.now() - 单位要统一为「秒」还是「毫秒」？ 缓存中存秒级时间戳（便于阅读和调试），比较时也统一转成秒；若存毫秒，所有地方都得保持毫秒，否则会错判过期（比如 12 小时被当成 12 毫秒）
-
异步写入不保证顺序：如果用
uni.setStorage（异步），value和deadtime可能写入失败一个，导致状态不一致 → 生产环境务必用setStorageSync同步写 -
key 冲突风险：后缀如
_deadtime要足够独特，避免业务 key 恰好以它结尾；可改用__expire_2026这类带年份的命名
要不要自动清理过期缓存？
严格来说，get 时发现过期就该清理对应 key 和 deadtime，否则缓存体积会缓慢膨胀——尤其用户长期不重装 App，uni.getStorageSync 遍历成本虽低，但无效 key 积累多了会影响 uni.clearStorageSync() 的语义清晰度。
但注意：不要在 app 启动时全量扫描并清理，因为 uni.getStorageInfoSync() 返回的 keys 是无序且不可预测长度的，遍历 + 解析每个 key 的 deadtime 会卡主线程，尤其低端机上明显卡顿。
推荐做法：只在 get 命中过期时顺手清理，既轻量又可持续收敛。
