localstorage容量不足时应通过捕获quotaexceedederror识别超限，优先清理低优先级数据（如temp_前缀、超7天缓存、损坏项），再重试写入；持续逼近上限时降级至indexeddb或localforage，并结合版本化配置管理实现安全清理与升级。
LocalStorage 存储空间不足时，不能只靠“catch 一下就完事”，得有一套可落地的降级策略：既要及时感知容量告急，又要保留关键数据、避免功能中断。
明确识别 QuotaExceededError 是唯一可靠信号
浏览器不提供剩余容量 API，navigator.storage.estimate() 返回的是整个 origin 的粗略估算，和 localStorage 实际可用空间偏差极大，尤其在隐身模式或 iOS Safari 下几乎不可信。真正有效的判断方式只有运行时试探 + 异常捕获：
- 写入操作必须包裹在 try-catch 中
- 仅当
e.name === 'QuotaExceededError'时确认为容量超限（不要依赖e.code === 22，兼容性差） - 错误发生后，不应直接报错退出，而应立即启动降级流程
优先清理无效/过期/低优先级数据
全量调用 localStorage.clear() 风险太高，可能清掉用户登录态、主题偏好等核心配置。更稳妥的做法是按规则精准剔除：
- 按 key 前缀批量清理（如
'temp_'、'cache_'开头的键） - 标记时间戳字段，自动淘汰超过 7 天的缓存项
- 对损坏数据（JSON 解析失败、字段缺失严重）做隔离清理，保留结构完整项
- 清理后立即重试写入，验证是否恢复可用
主动降级到更健壮的存储层
当单条数据 >100 KB 或总用量持续逼近 5–10 MB（Chrome 实测上限），应跳出 localStorage 思维：
- 切换至 IndexedDB：初始配额通常 50–250 MB，支持事务、二进制存储、精确容量估算
- 使用 localForage：封装了 IndexedDB/WebSQL/LocalStorage 的渐进增强方案，API 与 localStorage 高度一致，自动降级，支持直接存 ArrayBuffer、Blob、Object 等类型
- 小型项目可引入 LZString 压缩：对 JSON 数据压缩后再存，通常节省 50%+ 空间，且不增加兼容负担
配合配置管理机制，让降级“有据可依”
存储空间紧张时，往往也是配置结构升级、旧数据失效的高发期。把降级逻辑和配置版本管理绑定：
- 每次写入配置时附带
version字段（如{ version: "v3", data: { ... } }） - 读取时若发现版本不匹配，先尝试逐级映射升级，失败则 fallback 到
DEFAULT_CONFIG - 清理空间前，优先移除无 version 标识或 version 过老（如 v1）的配置项，保留新版有效数据
不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
