navigator.storage.estimate()是唯一可靠方式，返回usage（已用字节数）和quota（系统建议配额，单位字节），但quota可能为undefined，且仅在HTTPS或localhost安全上下文中可用。
Storage API配额不是固定值，取决于浏览器和上下文
浏览器不会给你一个写死的“10MB”或“250MB”配额承诺。实际可用空间由引擎动态分配，受设备存储、用户设置、站点是否为“高信任度”（如已添加到主屏幕、启用HTTPS、有用户交互）等影响。比如 Chrome 对 HTTPS + 用户激活的站点可能给到数 GB，而纯 HTTP 页面可能被限制在 128KB 甚至更低。
直接读 navigator.storage.estimate() 是唯一可靠方式——它返回的是估算值，不是硬上限，但能反映当前环境的真实水位。
怎么用 navigator.storage.estimate() 查真实配额
这个 API 返回 Promise，解析后含 usage（已用字节数）和 quota（系统建议配额，单位字节），注意：quota 可能为 undefined（如 Firefox 尚未实现配额反馈）。
- 必须在安全上下文（HTTPS 或
localhost）中调用，否则 Promise 会 reject 并抛出SecurityError - 不能在 iframe 中跨域调用，会触发
NotAllowedError - 返回值是估算，
quota不代表“还能写多少”，而是“浏览器目前愿意给你多少”，后续可能因内存压力收缩
if ('storage' in navigator && 'estimate' in navigator.storage) {
navigator.storage.estimate().then(({ usage, quota }) => {
console.log(`已用: ${usage} B`, `配额: ${quota ?? '未知'}`);
// 例如：已用: 4238912 B, 配额: 12884901888
}).catch(err => console.warn('配额查询失败:', err));
}
localStorage 和 indexedDB 共享 Storage API 配额吗
是的，在 Chromium 系（Chrome/Edge）和 Safari 中，localStorage、indexedDB、Cache API、Service Worker script 全部计入同一份配额池。你往 localStorage 写 5MB，再用 indexedDB 存 10MB，usage 就会累加显示为 ~15MB。
立即学习“前端免费学习笔记（深入）”；
但行为不完全一致：
-
localStorage写入超限会立即抛QuotaExceededError；而indexedDB在事务提交时才可能失败，且部分版本会静默截断 -
Cache API的清理策略更激进，浏览器可能在内存紧张时优先清空它，不影响usage统计，但会影响实际可用性 - Firefox 当前对
localStorage使用独立配额（约 10MB），不与其它 API 合并，navigator.storage.estimate()返回的usage也不包含它
配额快满了怎么办：别等报错，要主动监控
靠用户触发 QuotaExceededError 再处理太晚了——页面可能已卡死、数据丢失、甚至无法加载新资源（如果依赖 Cache API）。应该在关键操作前轻量探测：
- 在初始化 IndexedDB 连接后，立刻调用一次
navigator.storage.estimate()，缓存结果用于后续判断 - 当
usage / quota > 0.8（即使用率超 80%），提示用户“本地存储接近上限”，并提供清理入口（如清除缓存按钮） - 避免高频轮询：该 API 本身有开销，且结果短期稳定，每 5–10 分钟查一次足够
- 对 PWA 场景，可在
beforeinstallprompt触发后主动检查，因为安装成功后浏览器通常会提升配额
真正的麻烦点不在“怎么查”，而在“查出来之后浏览器不告诉你哪些数据能删”。storage API 没有暴露具体来源的 usage breakdown，得靠你自己按命名空间归类管理——比如所有 indexedDB 数据库名带 cache_ 前缀，就默认它们可安全清理。
