web storage 容量有限（5–10 mb），超限时 setitem() 抛 quotaexceedederror，应通过试探写入估算空间、分级存储（核心/中/低优先级）、try-catch 降级（改 sessionstorage/压缩/内存缓存）及迁移到 indexeddb 或服务端来应对。

Web Storage（包括 localStorage 和 sessionStorage）有容量限制（通常为 5–10 MB，因浏览器而异），一旦写入超出限额，setItem() 会抛出 QuotaExceededError，导致关键逻辑（如用户状态保存、表单草稿缓存）失败甚至页面卡死。规避的核心不是“拼命扩容”，而是主动监控 + 智能清理 + 容错兜底。

实时监测剩余可用空间

浏览器不提供直接读取剩余容量的 API，但可通过试探性写入估算：

• 预先生成一段固定长度的测试字符串（如 1KB），循环写入临时 key，直到抛错，反推已用空间
• 更轻量的做法：监听关键存储操作后的异常，结合 localStorage.length 和平均单条数据大小粗略预估（例如：若平均每条约 2KB，当前有 2000 条，则已用约 4MB）
• 建议在应用初始化和每次大体积写入前执行一次快速评估，避免高频探测影响性能

分级存储与自动清理策略

把数据按重要性/时效性分层，避免“一刀切”堆积：

• 高优先级数据（如登录凭证、用户偏好）：单独命名空间（如 __core__: 前缀），禁止被自动清理
• 中优先级数据（如页面草稿、筛选条件）：设置 TTL（时间戳字段），定期扫描过期项（如 7 天未访问则删除）
• 低优先级数据（如埋点缓存、日志快照）：采用 LRU 或 FIFO 策略，当空间紧张时优先丢弃最旧/最少用的条目

写入失败时的优雅降级

不能让 QuotaExceededError 直接中断业务流程：

• 所有 localStorage.setItem() 调用必须包裹 try-catch，捕获 QuotaExceededError
• 降级方案可选：改用 sessionStorage（适合临时数据）、压缩 JSON 后再存、或退回到内存缓存（注意页面刷新丢失）
• 对非关键数据，可记录警告日志并提示用户“本地缓存已满，部分功能可能受限”，而非报错弹窗

长期可维护的替代方案

当业务持续增长，单纯优化 localStorage 已不够：

• 对大量结构化数据，迁移到 IndexedDB（支持数十 MB 甚至 GB 级，且有事务和索引能力）
• 对需跨设备同步的数据，优先走服务端存储，前端只保留必要缓存，并配合 ETag 或版本号做一致性校验
• 考虑使用封装库如 localForage，它自动在 IndexedDB / WebSQL / localStorage 间降级，屏蔽底层差异