web storage容量超限需分层应对：先用textencoder精确预估utf-8字节长度并预留10%余量，再安全清理，最后降级技术栈。
Web Storage（localStorage/sessionStorage）达到容量限制后，不能只靠“清空重试”或忽略错误。真正有效的策略是分层应对：先预防超限、再安全清理、最后降级技术栈。
预估真实字节数，避免盲目写入
JavaScript 的 String.length 返回 UTF-16 字符数，但浏览器按 UTF-8 字节计费。一个中文字符占 2 字节，一个 emoji（如 “?”）占 4 字节，而 "?".length === 1。直接用 JSON.stringify(obj).length 估算必然失准。
- 用 new TextEncoder().encode(str).length 获取真实 UTF-8 字节长度
- key 名、JSON 引号、空格、换行都计入容量，预估时预留至少 10% 余量
- 小数据（
写入前轻探 + 异常捕获双保险
浏览器不提供剩余空间 API，最稳妥方式是“试探写入 → 成功即删 → 再正式写”。所有 setItem() 必须包裹 try-catch，专门处理 QuotaExceededError。
- 写入前执行 localStorage.setItem('probe', 'x')，成功后立即 removeItem('probe')
- catch 到 e.name === 'QuotaExceededError' 后，触发清理逻辑，再重试本次写入
- 绝不依赖 localStorage.length 或遍历所有 key 计算总长——它只返回项数，不反映字节总量
精准清理，不误删关键数据
调用 clear() 会一并清除登录态、token、主题偏好等核心字段，风险极高。应按命名约定和数据状态分类清理：
- 按前缀筛选：只操作 cache_、draft_、search_ 等非核心 key
- 优先删除过期项：读取 value 后 JSON.parse，检查 expiresAt 或 createdAt 字段
- 自动剔除损坏项：解析失败的值大概率是脏数据，可安全移除
- 清理后校验关键字段是否存在，例如确认 auth_token 仍在
容量持续逼近上限时，果断降级存储方案
localStorage 是同步、字符串-only、容量封顶的简易方案。当单条数据超 100 KB 或总量接近 5 MB，硬扛不如换技术栈：
- 改用 IndexedDB：通过 redux-persist-indexeddb-storage 可提升至数百 MB 容量，支持结构化查询
- 分片存储：将大数据切为多个 chunk 存入不同 key，读取时拼接还原
- 敏感或大体积数据交由服务端：前端只存 ID 或短期 token，减少本地负担
