Web Storage 错误捕获必须每次 setItem() 用 try-catch 实时拦截，因无容量查询 API 且 QuotaExceededError 仅写入时触发；需兼容多浏览器错误判定，并按数据重要性分级降级，优先 IndexedDB 替代。
Web Storage 的错误捕获不能靠“提前检查”，而必须在每次 setItem() 时用 try-catch 实时拦截——因为浏览器不提供查询剩余容量的 API，也没有跨平台统一配额值，QuotaExceededError 只在写入瞬间发生，且不可逆。
必须每次写入都 try-catch
不包裹就可能中断逻辑甚至白屏。这不是可选优化，而是强制防线：
- 不能只在初始化或登录后检查一次，必须对每一个
localStorage.setItem(key, value)单独防护 - 小数据试探更可靠：先写入一个短字符串（如
"test"）验证可用性，避免因对象序列化体积误判 - 未捕获的异常会冒泡到全局，触发
unhandledrejection或error事件，影响监控与稳定性
准确识别 QuotaExceededError
它不是独立构造函数，而是 DOMException 的一种命名错误。不同浏览器返回字段不一致，需兼容判断：
- Chrome/Firefox 主要用
err.name === "QuotaExceededError" - Safari 旧版本可能返回
err.name === "NS_ERROR_DOM_QUOTA_REACHED"或err.code === 1014 - Firefox 也可能用
err.code === 22（即DOMException.QUOTA_EXCEEDED_ERR） - 推荐封装判定函数，避免散落多处硬编码判断
熔断后分场景降级，不清理全部
捕获到错误只是起点，后续动作决定体验是否断裂：
- 非关键数据（如滚动位置、草稿、临时筛选状态）：可静默丢弃，并提示“本地缓存已满，当前操作未保存”
- 核心数据（如 token、主题、用户偏好）：优先尝试
sessionStorage（同源同窗口独立配额），再 fallback 到内存 Map 缓存 + 下次启动重拉 - 严禁调用
localStorage.clear()—— 它无差别删除所有键，极易误删登录态等关键字段 - 安全清理应按前缀（如
draft_）、时间戳（如 7 天前）或解析失败的脏数据逐项筛选
长期更可靠的方案是源头减负 + 技术升级
反复清理是补救，不是根治：
- 只存必要字段：用户信息保留
id、name、expiresAt即可，别存完整接口响应 - 改用
IndexedDB：配额更高（桌面端常达 50–250 MB），支持结构化查询与事务，适合中大型数据 - 对离线优先应用，结合
Cache API管理静态资源，把 localStorage 腾给真正需要持久化的轻量状态
