可靠判断 localstorage 是否已满的唯一方式是捕获 quotaexceedederror 异常，通过试探写入小值并异常捕获触发分级清理、预留安全空间、源头压缩与监控提示等综合策略保障存储稳定性。
Web Storage（主要是 localStorage）没有“已满”查询接口，也不能靠 localStorage.length 或字符串化后算长度来准确判断剩余空间。真正可靠的清理起点，是捕获写入失败时抛出的 QuotaExceededError——这才是浏览器明确告诉你“没地方了”的信号。
用试探写入 + 异常捕获触发清理
不要等用户操作卡住才响应。把写入封装成带兜底逻辑的方法：
- 尝试存入一个极小的测试值（比如
"test"），避免因单次写入过大误判容量 - 捕获
QuotaExceededError后立即执行清理函数，再重试原写入 - 清理前优先备份关键字段（如
auth_token、theme），防止清空误伤核心状态 - 不依赖
JSON.stringify(localStorage)计算大小——它本身可能触发异常，且无法反映真实字节占用
按策略清理，而非盲目清空
clear() 是最简单粗暴的方式，但会丢失所有用户偏好和登录态。更稳妥的做法是分级处理：
- 对每项数据约定结构，例如存储时附带
expires时间戳字段：{ value: "...", expires: 1745000000000 } - 遍历所有 key，解析内容后比对时间戳，只删除过期项
- 对非时效性数据（如用户设置），按最后访问时间（需额外记录
lastUsed）淘汰最久未用的 N 条 - 保留最小安全集：至少留出 200KB 空间，确保下次登录态、错误日志等关键写入能成功
从源头降低存储压力
清理是补救，预防才是重点。日常开发中可落地的控制手段：
- 写入前用
new TextEncoder().encode(str).length预估 UTF-8 字节数，大对象（如图片 base64）直接拒绝存 localStorage - 敏感或临时数据改用 sessionStorage；大量结构化数据迁移到 IndexedDB（容量可达数百 MB）
- 引入压缩：对 JSON 状态用 lz-string 压缩后再存，通常节省 60%–80% 空间
- 统一接入封装类（如
StorageManager），所有读写走同一入口，自动埋点、限流、降级
配合监控与用户提示
纯后台清理不够透明。建议加一层轻量反馈：
- 定期（如每 5 分钟）估算当前使用率：用
getStorageUsage()（Chrome/Edge 支持）或采样估算 - 当使用率超 80%，在设置页角落显示小提示：“本地存储已使用较多，部分缓存可能被自动清理”
- 清理发生后，记录日志并上报（不传敏感内容），用于分析高频耗尽场景
- 若清理后仍失败，降级到内存缓存 + 提示用户手动清理，而不是静默丢数据
