localStorage 存储空间约5MB，超限时抛出QuotaExceededError；需通过试探法估算剩余空间、分级清理（惰性/定期/空闲）、命名空间隔离及版本感知机制实现可靠管理。
localStorage 的存储空间不是无限的，浏览器通常只给每个域名分配约 5MB。一旦接近上限，写入操作就会失败，抛出 QuotaExceededError。单纯依赖“用完再清”或“手动清空”不可靠——用户不会主动清理，而错误往往在关键时刻才暴露。真正有效的策略，是把空间检查和清理变成自动、轻量、可感知的过程。
实时容量检测：用试探法估算剩余空间
localStorage 没有直接 API 返回已用/剩余容量，但可通过“写入试探”安全估算：
- 准备一段固定长度的测试字符串（例如 10KB 的重复字符）
- 尝试连续写入，直到触发
QuotaExceededError - 记录成功写入次数，反推当前可用空间（注意避开已有数据干扰，建议使用临时 key）
- 实际项目中，可在应用启动或用户登录后执行一次轻量试探，缓存结果用于后续预警
不推荐频繁全量试探——它本身会占用空间且影响性能。更实用的做法是：结合业务数据大小做预估（如单条商品缓存 ≈ 2KB），当累计写入量接近 4MB 时，就触发清理流程。
分级清理机制：惰性 + 定期 + 空闲三重保障
单一清理方式都有短板。生产环境应组合使用：
-
读取时惰性清理：每次
getItem都校验过期时间，过期即删。这是最基础、零成本的防线，确保返回的数据一定有效 -
低频定期扫描：用
setInterval每 5–10 分钟遍历一次 key 列表，批量移除过期项。注意控制扫描粒度（如每次最多处理 50 条），避免阻塞主线程 -
空闲期深度清理：借助
requestIdleCallback，在浏览器空闲时执行完整扫描或压缩操作。适合做空间整理、合并碎片、甚至 LRU 淘汰
这三层不是并行开销，而是按需激活：日常靠惰性，后台靠定时，大扫除靠空闲——资源利用率高，用户体验无感。
命名空间隔离 + 按模块清理：避免误伤与精准回收
所有数据混存在一个全局池里，清理时容易“伤及无辜”。解决办法是结构化管理：
- 为不同功能模块设置前缀，如
auth_token、form_draft_v2、catalog_cache_202606 - 清理时可按前缀批量操作：
Object.keys(localStorage).filter(k => k.startsWith('form_draft_')).forEach(k => localStorage.removeItem(k)) - 关键数据（如登录态）单独归类，设置更长 TTL 或禁用自动清理；临时数据（如搜索历史）则启用短 TTL + 高频清理
这样既防止键名冲突，也让清理逻辑可配置、可追溯、可灰度——比如先对“浏览记录”模块开启清理，观察一周后再推广到“草稿箱”。
版本感知清理：应对代码升级与数据格式变更
前端发版后，旧缓存可能因结构变化失效，甚至引发解析错误。加入版本号是低成本高收益的做法：
- 在 localStorage 中存一个
app_version键，值为当前构建版本（如"v2.3.1"） - 每次初始化时比对：若本地版本不匹配，清空所有业务数据（保留用户显式设置项如主题色，可单独判断）
- 也可更精细——只清对应模块的缓存，例如
catalog_version单独管理商品列表缓存
这相当于给缓存加了一道“准入闸机”，避免新旧代码与旧数据之间产生兼容性问题，尤其适合快速迭代的中后台系统。
