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 可能瞬间归零——这时任何写入都会立刻失败，且不会触发配额警告。
