localStorage 不会自动清理？封装一套带寿命的缓存方案

经常有前端开发者遇到这种尴尬场景：为了减少接口请求，把用户信息或临时状态存入 localStorage，结果几个月后发现数据还在那儿。虽然浏览器本身没有报错，但业务逻辑上这串过期数据已经失去了意义。原生 localStorage 的设计初衷就是持久化存储，除非手动清除，否则它会一直跟着用户直到硬盘被填满。这听起来很稳定，但在需要灵活控制数据生命周期的场景下，却成了个大坑。

要想解决这个问题，核心思路其实很简单：给数据加上“时间戳”外衣。我们在存入时记录当前时间，读取时对比现在时间与记录时间的差值。不过，千万别在每次调用地方手写这套判断逻辑，既冗余又容易遗漏。更好的做法是将其封装成一个独立工具，把复杂度隐藏起来。

基础结构定义

我们需要存储的内容不再仅仅是字符串，而是一个包含元数据的对象。通常包含两个字段：一个是实际的值（value），另一个是过期时间戳（expire）。假设我们要存一条用户 Token，数据结构应该是这样的：

{
  v: "eyJhbGciOi...", // 实际数据
  e: 1715600000000 // 过期时间戳 (ms)
}

这样做有个明显优势：分离了数据和元数据。即使未来你想增加版本控制或加密信息，只需要在这个结构里加字段即可，无需改动底层存取逻辑。

封装读写方法

有了结构，接下来的关键是实现安全的存取。重点在于读取时的健壮性。因为 localStorage 中可能存在旧格式的数据，或者非本工具写入的脏数据，直接解析可能会抛出异常。

我们需要在获取数据时包裹一层 try-catch。当发现存储损坏、JSON 解析失败，或者当前时间超过了存储的时间戳，就应该视为失效。这时不仅返回空值，还必须执行 物理删除操作。这一点很重要，如果不及时清理过期的键，日积月累会占用宝贵的配额空间。

下面是简化后的实现思路，你可以直接复用并稍作修改：

const Storage = {
  set(key, value, expireMinutes) {
    const data = {
      v: value,
      e: Date.now() + expireMinutes * 60 * 1000
    };
    try {
      localStorage.setItem(key, JSON.stringify(data));
    } catch (e) {
      console.warn('Storage full or serialization error', e);
    }
  },
  get(key) {
    try {
      const item = localStorage.getItem(key);
      if (!item) return null;

      const parsed = JSON.parse(item);
      // 校验是否存在且未过期
      if (Date.now() > parsed.e) {
        localStorage.removeItem(key); // 立即清理过期数据
        return null;
      }
      return parsed.v;
    } catch (e) {
      // 解析出错视为无效数据
      localStorage.removeItem(key);
      return null;
    }
  }
};

几个容易被忽略的细节

在实际项目中，光有上述逻辑还不够。比如，如果你依赖某个第三方库往 localStorage 写入了纯文本，而你的工具尝试去 JSON.parse 它，程序就会崩掉。所以，错误捕获和回退策略不能少，上面的代码示例中已经体现了这一点：一旦出错，直接视作不存在并移除该键，保证系统不中断。

还有一个边界情况是跨标签页同步。如果一个页面判定数据过期并删除了它，另一个打开的同域名标签页可能还没来得及检查。这是浏览器存储机能的限制，无法完全避免。通常的处理建议是：以最后一次读取为准，如果读到 null 就重新请求服务端拉取新数据。不要试图通过复杂的广播机制去同步状态，那会增加不必要的维护成本。

总结

给 localStorage 加上有效期，本质上是对数据生命周期的管理。我们追求的不是存储的最大化，而是数据的有效性。通过简单的封装，将过期判断逻辑内聚，能让后续的业务代码更加清爽。当你再次面对那些不知何时会产生副作用的本地数据时，不妨花几分钟做一下这个加固，毕竟干净的缓存环境才是高性能的基础。