navigator.storage.estimate() 是唯一标准 api，返回当前源总存储 usage 和 quota 估算值，不区分缓存类型；需结合 cache api 遍历、localstorage/indexeddb 手动统计来近似归因各类占用。
浏览器缓存空间不是固定值，而是由底层存储机制（如 QuotaManager）动态分配的，navigator.storage.estimate() 是目前唯一标准 API，用于获取当前源（origin）的已用空间和总配额估算值。它本身不区分“各类缓存”（如 HTTP 缓存、Service Worker Cache API、IndexedDB、localStorage 等），而是返回整个 origin 的**存储总览**。但你可以结合 JS 主动探测 + 逻辑推断，近似判断不同存储类型的占用情况。
理解 estimate() 返回值的真实含义
navigator.storage.estimate() 返回一个 Promise，解析为对象：{ usage: number, quota: number }
- usage：当前 origin 所有持久化存储（Cache API、IndexedDB、localStorage、Web SQL、字体缓存等）占用的字节数估算值，不含网络层 HTTP 缓存（如 disk cache），因为 HTTP 缓存不由 JS 控制，也不计入 Storage Standard。
- quota：浏览器为该 origin 分配的存储配额上限（字节），受设备空闲空间、用户行为（如是否设为“站点可离线使用”）、浏览器策略（如 Chrome 对非安全上下文限制为 0）影响，不是固定值，且不同浏览器差异较大。
配合 Cache API 主动管理并反向估算缓存占比
虽然无法直接读取 Cache API 的精确大小，但可通过遍历 cache entries 并累加 response headers 中的 Content-Length（或响应体 blob.size）做合理估算：
async function estimateCacheSize(cacheName) {
try {
const cache = await caches.open(cacheName);
const requests = await cache.keys();
let total = 0;
for (const req of requests) {
const res = await cache.match(req);
if (res) {
// 优先用 Content-Length， fallback 到 blob.size（可能触发解压/解码）
const len = res.headers.get('Content-Length');
if (len) {
total += parseInt(len, 10);
} else {
const blob = await res.blob();
total += blob.size;
}
}
}
return total;
} catch (e) {
return 0;
}
}
<p>// 使用示例
async function showStorageBreakdown() {
const { usage, quota } = await navigator.storage.estimate();
const cacheUsage = await estimateCacheSize('my-app-cache');
console.log(<code>总占用: ${usage} B, 配额: ${quota} B</code>);
console.log(<code>Cache API 估算占用: ${cacheUsage} B (${((cacheUsage / usage) * 100).toFixed(1)}%)</code>);
}</p>⚠️ 注意：遍历大量缓存项可能阻塞主线程；blob.size 在某些响应类型（如 stream、opaque）下不可靠；建议仅在开发调试或低频检查时使用。
结合 IndexedDB 和 localStorage 做粗略归因
对其他主要存储，可手动统计：
-
localStorage：逐个 key 调用
JSON.stringify(localStorage[key]).length（UTF-16 字符 ×2 ≈ 字节数） -
IndexedDB：打开 DB 后遍历所有 objectStore，用
cursor.value序列化后估算大小（同上），或使用 idb library 的封装辅助
这些统计结果相加，再与 usage 对比，能验证估算合理性（例如：sum(local, idb, cache) ≈ usage × 0.8~0.95），差值部分通常是浏览器内部元数据、字体缓存或未暴露的临时 blob 存储。
实用建议：构建轻量级缓存健康看板
不追求绝对精确，而是建立可操作的监控维度：
- 监听
storage事件 + 定期调用estimate()，当usage / quota > 0.8时触发清理策略（如删除最旧 Cache 版本、压缩 IndexedDB 大附件） - 为 Cache API 设定命名规范（如
v1-main,v1-images），分别估算，识别“哪类资源吃掉最多空间” - 在 DevTools → Application → Storage 中手动对比，验证 JS 估算是否在合理区间（通常误差
真正影响用户体验的是“是否因配额不足导致 cache.put 失败”或 “IDB transaction abort”，因此更推荐在关键写入操作后捕获异常，并回退到内存缓存或降级策略，而非过度依赖空间预判。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
