直接捕获 QuotaExceededError 并清理是解决 localStorage 爆满最实际兼容的方式，需对每次 setItem 做 try-catch 防护、策略性清理非核心 key、源头减负存必要字段并压缩、配合监控与 indexedDB 降级。

直接捕获 QuotaExceededError 并清理，是解决 localStorage 爆满异常最实际、最兼容的方式。浏览器不提供“剩余容量”API，也无法精确预估字节数，硬算或轮询都不可靠——关键在于让写入逻辑具备容错与自愈能力。

用 try-catch 触发清理，而不是等它崩

localStorage 写入失败时只会抛出 QuotaExceededError（部分旧版用 code === 22），不会静默截断或部分写入。必须包裹所有 setItem 调用：

• 不要只在初始化时检查一次容量，要对每次写入都做防护
• 测试数据用极小字符串（如 "test"），避免因单次写入过大误判为满
• 清理后建议重试一次，而非直接丢弃本次数据

清理不能一刀切，得有策略和边界

localStorage.clear() 会清掉登录态、主题偏好、token 等关键数据，风险极高。安全清理需满足三点：

• 按前缀分类 key：如 cache_、draft_、search_，只动非核心类
• 优先删过期项：读取 value 后尝试 JSON.parse，检查 expiresAt 或 createdAt 字段
• 删损坏项：解析失败的 value 往往是脏数据，可直接移除

从源头减负，比事后补救更有效

反复清理治标不治本。真正降低爆满概率，要控制写入内容本身：

• 只存必要字段：用户信息不存完整响应，只留 id、name、expiresAt
• 禁存 base64 图片、二进制 blob、HTML 片段等大体积内容，改用 URL 引用
• 长文本类数据（日志、草稿）可用 lz-string 压缩，纯文本压缩率常达 60%+
• 写入前粗略估算：new TextEncoder().encode(JSON.stringify(value)).length，叠加已有用量预判

监控与兜底方案要跟上

线上问题往往暴露滞后。建议加两层保障：

• 页面加载后空闲时扫描 key，清除 7 天前的临时项（不影响首屏）
• 当 localStorage 持续接近上限（如 > 4.5MB），上报监控平台，辅助定位谁在狂写
• 对超大结构数据（如文件列表、离线消息），直接降级到 indexedDB，用 localForage 封装更省心