navigator.storage.estimate使用方法与缓存优化技巧

`navigator.storage.estimate()` 并非可靠的磁盘用量探测器，其返回的 quota 是受设备、系统压力和用户行为影响的动态软上限，尤其在 iOS Safari 中常失效为 `{usage: 0, quota: 0}`；真正决定缓存成败的是写入时的 `QuotaExceededError`，而非估算值——因此高效缓存的关键不在于“精算水位”，而在于将 `estimate()` 视为趋势信号，结合失败兜底、渐进式清理（优先使用轻量可控的 `cache.keys()`）、移动端强制降级（如固定条目数+计数器+资源压缩），构建对错误敏感、边界清晰、跨平台稳健的弹性缓存策略。

为什么 navigator.storage.estimate() 返回的 quota 常常不准

浏览器对 quota 的估算不是实时磁盘用量，而是基于当前 origin 的“配额策略”动态分配的软上限，受设备类型、存储压力、用户行为（如是否开启无痕模式）影响极大。Chrome 在桌面端可能返回 10GB，但实际写入 2GB 就触发 QuotaExceededError；Safari 则可能直接限制在 50MB 且不随 estimate() 数值变化。

所以不能用 used / quota > 0.9 这类静态阈值做判断——它在不同环境会失效。

• navigator.storage.estimate() 的 quota 是建议值，不是硬边界
• 真实溢出往往发生在 cache.put() 或 indexedDB 写入时，而非调用 estimate() 后立刻发生
• 移动端（尤其 iOS Safari）几乎不暴露可靠 quota，estimate() 可能返回 {usage: 0, quota: 0}

如何用 estimate() + 回退策略做安全缓存调节

核心思路是：把 estimate() 当作趋势信号，而非绝对水位尺；配合写入失败兜底和渐进式清理。

• 每次准备写入前，调用 navigator.storage.estimate()，仅关注 usage 是否明显增长（比如比上次记录 +20MB），而不是算百分比
• 维护一个本地记录 lastKnownUsage（存在 localStorage 或内存），避免频繁调用 estimate()（它本身有性能开销）
• 真正决定是否清理缓存，依据是最近一次 cache.put() 是否抛出 QuotaExceededError，或 indexedDB.open() 失败
• 清理时优先剔除最旧的、非关键资源（如图片缩略图），保留 manifest.json、主逻辑 JS 等

示例逻辑片段：

async function safeCachePut(cacheName, request, response) {
  try {
    const cache = await caches.open(cacheName);
    await cache.put(request, response);
  } catch (err) {
    if (err.name === 'QuotaExceededError') {
      await evictOldAssets(cacheName, 30); // 清理 30% 最旧条目
      // 再试一次
      const cache = await caches.open(cacheName);
      await cache.put(request, response);
    }
  }
}

cache.keys() 和 indexedDB 清理哪个更可控

cache.keys() 返回的是 Request 对象数组，可按 url 和 timestamp（需自己存）排序，清理粒度细、无副作用；而 indexedDB 清理需事务、游标、版本升级，容易卡住主线程，且无法精确控制释放量。

• 如果主要用 Cache API 存资源，优先用 cache.keys() + cache.delete() 渐进清理
• 若混合使用 indexedDB，清理前先调用 db.close()，否则可能因连接占用导致清理失败
• 不要在 fetch 事件中同步清理——会阻塞网络响应；改用 setTimeout(() => { ... }, 0) 或 queueMicrotask

移动端 iOS Safari 的特殊处理必须做

iOS Safari 不支持 navigator.storage.estimate()（返回 Promise.resolve({usage: 0, quota: 0})），也无法通过 cache.keys() 获取完整键列表（只返回部分）。这意味着你无法靠估算驱动清理逻辑。

• 必须启用降级开关：检测到 quota === 0 时，强制启用「固定配额模式」——例如只允许缓存最多 200 个资源，超出即轮转删除
• 用 performance.memory（如有）或简单计数器模拟用量，比如每 cache.put() 一次就 localStorage.setItem('cacheCount', ++count)
• 对图片等大文件，强制压缩或降质再缓存，避免单个请求就触顶（iOS 实际硬限常为 50–100MB/origin）

离线缓存的弹性不来自精确配额计算，而来自对失败的快速响应和对清理边界的明确约束。浏览器不会告诉你“还剩多少”，但总会用错误告诉你“已经满了”。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《navigator.storage.estimate使用方法与缓存优化技巧》文章吧，也可关注golang学习网公众号了解相关技术文章。