LocalStorage 无内置 LRU 机制，需手动实现时间戳+排序清理；可选 FIFO 或 TTL 等轻量方案，但须规避遍历原型链、键不一致、多标签同步等风险。
LocalStorage 本身不内置清理算法，也没有原生支持 LRU（Least Recently Used）机制。它只是一个简单的键值对持久化存储接口，所有清理动作都必须由开发者手动实现。
为什么 LocalStorage 需要自己实现 LRU
浏览器对 localStorage 的配额有限（通常 5–10MB），但它的写入是无序、无时间戳、无访问记录的。当你缓存大量数据（比如搜索历史、API 响应、表单草稿）时，很容易因空间不足触发 QuotaExceededError。而浏览器不会自动淘汰旧数据——它只会报错，把问题甩给前端逻辑。
LRU 是一种合理且实用的应对策略：保留最近用过的数据，清掉长时间未碰的项，既控制体积，又尽量维持命中率。
如何手动实现 LRU 清理逻辑
核心思路是：为每个 key 维护一个“最后使用时间”，定期按时间排序，删掉最老的若干条。由于 localStorage 不支持元数据存储，这个时间戳必须和值一起存，或单独用 key 管理。
- 写入时记录时间：每次
setItem(key, value)同时存一个对应的时间戳 key，例如localStorage.setItem(`${key}__ts`, Date.now().toString()) - 读取时更新时间：调用
getItem(key)后，立刻再写一次时间戳，确保它反映“最新访问” - 清理时排序筛选：遍历所有 key（用
for (let i = 0; i ），提取带__ts后缀的时间戳，按数值升序排列，批量removeItem最老的 N 个主 key 及其对应时间戳 - 避免污染业务 key：建议统一前缀，如
cache_user_list和cache_user_list__ts，清理时只处理以cache_开头的项
更轻量的替代方案：FIFO 或 TTL
如果你不需要精确到“访问频次”，只是想防爆满，可以考虑更简单的方式：
-
FIFO（先进先出）：用一个队列数组存 key 顺序，每次写入 push 到末尾，清理时 shift 掉开头几个；队列存在单独的 key 如
__cache_queue中，用 JSON 存储和维护 -
TTL（过期时间）：写入时存一个过期毫秒数，如
{"value": "...", "expires": 1742432400000}，读取前检查Date.now() > expires，过期则自动删除并返回 null - 两者都比完整 LRU 实现成本低，适合中低频缓存场景，比如配置项、用户偏好同步状态等
注意别踩的坑
直接在 localStorage 上做 LRU 很容易引入隐患：
- 不要用
for...in遍历 localStorage——它会遍历原型链，可能报错或误删 - 时间戳 key 和主 key 必须成对操作，否则清理时只剩一半，造成数据残留或不一致
- 多标签页环境下，storage 事件无法通知本页自身操作，所以时间戳更新后，其他 tab 才能感知；若强依赖实时性，需配合 BroadcastChannel 或 IndexedDB
- 压缩或序列化后的数据体积难估算，LRU 清理前最好用
encodeURIComponent(JSON.stringify(val)).length预估真实字节，避免删了 10 个 key 却只腾出几百字节
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
