localstorage无垃圾回收机制，数据永不自动过期；所谓“碎片”指逻辑失效却长期滞留的数据，表现为键名重复、结构残留、空值占位及调试残留等语义混乱问题。
浏览器根本不会对 localStorage 做垃圾回收，它压根没有“过期自动清理”机制。所谓“碎片”，不是内存意义上的碎片，而是指那些早已失效、逻辑上该被丢弃却长期滞留的数据项——它们占着位置、干扰判断、可能引发业务异常，但浏览器完全不管。
localStorage 本身不支持自动过期
标准规范里，localStorage 是纯持久化存储：只要用户不手动清除、网站没调用 removeItem 或 clear，数据就永远存在。哪怕存的是三天前的 token、上周的临时配置、已废弃版本的 UI 状态，浏览器也照单全收、纹丝不动。
这意味着：
- 没有后台线程扫描过期时间
- 不按访问频次淘汰冷数据
- 不因容量告警自动压缩或清理
- 不响应系统存储压力做策略性释放
“碎片”的真实表现：不是空间碎，是语义乱
所谓“碎片”，常体现为这几类问题：
-
键名重复但含义错位：比如
"user_prefs_v2"和"user_prefs"同时存在，实际只该保留新版 - 过期结构残留：旧版接口返回的嵌套对象格式，新代码已改用扁平字段，但老数据仍在 key 里躺着
-
空值或 null 字符串占位：
setItem("cart", "")或setItem("token", "null")后未清理，后续逻辑误判为有效状态 -
调试残留键：开发时写入的
"debug_mode"、"mock_api"长期未删除，上线后意外生效
如何识别这些“隐形碎片”
靠人工翻控制台不现实。建议从三方面主动探测：
-
遍历比对时间戳：若项目约定所有带过期逻辑的数据都存为
{ value, expires: timestamp }格式，可遍历所有 key，解析 JSON 后检查expires 的数量和占比 -
统计键名模式异常：正则匹配如
/^v\d+_.+$/、，发现多版本并存线索
-
监控 getItem 返回异常值：在封装的读取方法中加日志，记录返回
null、<code>""、"undefined"或无法 JSON.parse 的 key —— 这些往往是“半死”碎片的信号
真正有效的清理必须由代码驱动
不能等浏览器出手。两种主流可控方式：
-
惰性清理：每次
getItem时校验并移除过期项（适合读多写少、对首屏无强性能要求的场景） -
启动时批量扫描：页面加载完成（
DOMContentLoaded）后，用setTimeout延迟执行轻量扫描（例如每次查 3 个 key，分片处理），避免阻塞渲染
注意：不要用 setInterval 持续轮询 —— 页面后台运行时仍会消耗资源，且多数场景无需实时性。
