navigator.storage.estimate() 返回的是总配额上限,非剩余空间;剩余空间需计算 quota - usage,且该值仅为近似估算,受浏览器实现、缓存统计粒度及运行模式影响。

navigator.storage.estimate() 返回的 quota 是总配额还是剩余配额?
它返回的是浏览器为当前源(origin)分配的**总存储配额上限**(quota),不是剩余可用空间。真正反映“还能写多少”的是 quota - usage,而 usage 表示当前已用的字节数。
注意:这个估算值是近似值,尤其在使用 Storage Foundation(如 Chromium 的 Site Data Manager)时,usage 可能不包含部分缓存或临时文件,且不同浏览器对“usage”的统计粒度不一致。
常见错误现象:
• 直接把 estimate().quota 当作“剩余空间”使用,导致写入失败
• 在 Safari 或旧版 Firefox 上调用报 undefined 或 Promise rejected
如何安全调用 navigator.storage.estimate() 并处理兼容性?
必须确保环境支持、上下文合法,并做好降级准备:
-
navigator.storage在非安全上下文(HTTP)中为undefined,仅 HTTPS 或localhost有效 - Firefox 55+、Chrome 61+、Edge 79+ 支持;Safari 11.1+ 仅部分支持(
estimate()存在但quota常为0或不更新) - 需用
try/catch包裹异步调用,避免因权限拒绝(如用户禁用第三方 Cookie)导致未捕获异常
简单实操示例:
if ('storage' in navigator && 'estimate' in navigator.storage) {
navigator.storage.estimate().then(({ usage, quota }) => {
const remaining = quota - usage;
console.log(`已用 ${usage} 字节,总配额 ${quota} 字节,剩余约 ${remaining} 字节`);
}).catch(err => {
console.warn('无法获取存储估算:', err);
});
} else {
console.log('当前浏览器不支持 navigator.storage.estimate');
}
为什么 estimate() 的结果有时和实际写入能力不符?
根本原因在于浏览器对“存储配额”的计算逻辑与开发者预期存在偏差:
- 配额不是固定值,会动态调整:例如 Chrome 会根据磁盘空闲空间、用户活跃度、同源站点数量等重新分配
quota -
usage不包含所有类型数据:IndexedDB 中某些 blob 引用、Cache API 的响应体、甚至 Service Worker 脚本缓存,可能未被完全计入 - 写入失败不一定因“超 quota”:也可能是磁盘满、OS 权限限制、或浏览器主动拒绝(如隐身模式下 quota 被强制设为 0)
- 同一 origin 下多个 tab 共享 quota,但
usage统计有延迟,短时间内并发写入易误判
真正想预估“还能不能写”,该怎么做?
靠 estimate() 只能粗略参考,生产环境应结合主动探测:
- 预留 buffer:比如显示“剩余 5MB”,实际在写入前检查是否 ≥ 10MB,避免临界失败
- 小步试探写入:先尝试写入一个
1MB的Blob到 IndexedDB,捕获QuotaExceededError后回滚并提示用户 - 监听 storage 变化:用
storage事件 + 定期重估,比单次调用更可靠 - 不要依赖
quota绝对值:Chrome 可达数 GB,Safari 常卡在 50–200MB,且无明确文档说明阈值规则
最常被忽略的一点:即使 estimate() 显示还有空间,如果用户刚清过浏览数据、或处于隐私浏览模式,quota 可能瞬间归零——这时任何写入都会立刻失败,且不会触发配额警告。










