indexeddb 无法直接获取单个对象仓库的物理磁盘容量，因浏览器出于安全隐私不暴露底层存储细节，且数据与缓存、日志等共享存储池，压缩策略、索引元数据等导致物理布局不透明。
JavaScript 中的 IndexedDB 无法直接获取单个对象仓库（Object Store）占用的实际物理磁盘容量。
浏览器不暴露底层存储大小信息
IndexedDB 是浏览器提供的抽象数据库接口，其底层由浏览器引擎（如 Blink、Gecko）管理，具体存储可能经过压缩、去重、日志合并、垃圾回收等处理。浏览器出于安全和隐私考虑，不提供 API 查询某 object store 占用多少字节的磁盘空间。即使是 indexedDB.webkitGetDatabaseSize（旧版 Chrome 实验性 API）或 storage.estimate()，也只返回整个 origin 的粗略估算值，且不区分数据库或对象仓库。
可用的间接估算方法
虽然无法精确读取物理磁盘占用，但可通过以下方式做近似估算：
-
序列化后计算 JSON 字符串长度：遍历 object store 中所有记录，对每条值调用
JSON.stringify(value).length（注意：这仅反映 UTF-16 字符数，不是真实字节；且忽略键名、索引、元数据开销） -
使用
size属性（仅限 Blob/File）：若 object store 存储的是Blob或File，可直接访问blob.size求和，这部分较接近实际磁盘占用 -
结合
storage.estimate()做差值法：在清空某 object store 前后各调用一次navigator.storage.estimate()，观察usage变化（误差较大，受缓存、其他存储干扰）
为什么不能精确统计
原因包括：
- IndexedDB 数据通常与浏览器缓存、QuotaManager、LSM-tree 日志等共享存储池，物理布局不透明
- 同一数据在不同浏览器中压缩策略不同（例如 Chromium 使用 Snappy，Firefox 使用 LZ4）
- 索引、事务日志、版本元数据、碎片空间均计入磁盘但不可见
- 跨 origin 存储配额是统一管理的，无法按 object store 切分
实用建议
如需控制存储规模，推荐做法是：
- 设计时为关键字段预估大小（例如一个 1MB 的 ArrayBuffer 存入后实际磁盘占用约 1–1.2MB）
- 用
IDBKeyRange分页遍历 +JSON.stringify累加估算“逻辑大小”，作为监控阈值参考 - 监听
quotaexceeded异常，配合navigator.storage.estimate()主动清理低优先级数据 - 避免依赖精确字节数，改用记录数 + 典型单条大小做容量规划
不复杂但容易忽略：浏览器永远只告诉你“还能用多少”，不会告诉你“这个表占了多少”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
