html5 中无法直接获取各存储方式独立配额，但可通过 navigator.storage.estimate() 获取 origin 下所有持久化存储总用量（usage）和软配额上限（quota），该值包含 indexeddb、cache api 等，不包含 localstorage；localstorage 需用 textencoder 单独估算 utf-8 字节数；usage/quota 比值＞0.85 时写入失败风险高，应清理旧数据；quotaexceedederror 是最终判据，须监听并捕获处理。
HTML5 中无法直接获取各存储方式（IndexedDB、Cache API、localStorage）的独立配额或精确字节数，但可以通过 navigator.storage.estimate() 获取整个 origin 下**所有持久化存储的总用量估算值（usage）和浏览器分配的软配额上限（quota）**。这个总值包含 IndexedDB、Cache API、Service Worker 缓存等，但不包含 localStorage 和 sessionStorage——它们走的是另一套独立配额机制，需单独估算。
用 estimate() 监控整体持久化存储压力
navigator.storage.estimate() 是目前唯一标准、跨浏览器可用的“总消耗占比”参考依据。重点不是看 quota - usage 的绝对差值，而是看 usage / quota 比值：
- 比值 > 0.85：写入 IndexedDB 或 Cache API 失败概率显著升高，应主动清理旧数据
- 比值 ≈ 0 或
quota === 0：常见于 Safari（17.5 及更早）、无用户交互的 Chrome、隐身模式，此时应降级为仅依赖错误捕获 - 该比值稳定可比，能过滤掉不同浏览器返回的 quota 差异（Chrome 可能报 TB 级，Safari 常报 0），而绝对字节数反而失真
单独估算 localStorage 占用（非持久化，但需计入总盘面）
localStorage 不参与 estimate()，但它实际占用磁盘空间，且超限会抛 QuotaExceededError。可用 TextEncoder 较准确估算其 UTF-8 字节占用：
- 遍历所有 key：用
localStorage.key(i)+localStorage.getItem(key) - 对每个 key 和 value 分别调用
new TextEncoder().encode(str).length得 UTF-8 字节数 - 累加后与典型配额对比（如保守按 5 MB = 5,242,880 字节），计算本地占比
- 注意：不能用
JSON.stringify(localStorage).length * 2，那算的是 UTF-16 码元，严重高估中文/emoji 占用
定位“谁在吃空间”：分项排查高消耗源
当 usage / quota > 0.9 时，仅看总比值不够，必须拆解源头：
- 查 IndexedDB：调用
indexedDB.databases()（支持浏览器中）获取已建库列表；对每个库打开并统计 objectStore 记录数或粗略估算 blob 大小 - 查 Cache API：用
caches.keys()列出所有缓存名，再用caches.open(name).keys()统计请求条目，结合响应体大小预估（需 fetch 后读取response.clone().arrayBuffer().then(buf => buf.byteLength)） - 查 localStorage：用上一步的 TextEncoder 方法汇总
- 注意：sessionStorage 不计入任何配额监控，它随标签页生命周期自动释放，无需主动管理
异常驱动补充：QuotaExceededError 是最终判据
无论估算多准，真实瓶颈始终由运行时错误揭示：
- 监听
indexedDB.open().onerror和事务onerror，检查event.target.error.name === 'QuotaExceededError' - localStorage.setItem() 必须每个都 try/catch，捕获
QuotaExceededError和SecurityError（尤其 Safari 无痕模式） - 一旦捕获，立即停止新写入，并触发对应存储的清理策略（如删 7 天前日志、清最老 cache、压缩长文本字段）
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
