基于IndexedDB的虚拟文件系统：Int8Array存储有效性验证

作为一直在折腾IndexedDB存储优化的开发者，我来帮你梳理下验证方法，还有你遇到的那些问题的原因：

一、验证存储有效性的具体方法 #

1. 实际占用空间验证 #

• Chromium系浏览器（Chrome/Edge等）：
  你用的「清除存储」页面显示的是IndexedDB的总占用量，包含了数据库元数据、索引、预分配的空闲空间、事务日志等，不是单纯你写入的数据大小。要更精准的话，可以打开DevTools的「Application」面板→「IndexedDB」→选中你的数据库，查看每个对象存储的「Size」列，这个数值更接近实际数据+必要开销的总和。
  另外还可以用performance.measureMemory() API（需要HTTPS或localhost环境），它能更细致地测量存储占用，不过返回的是近似值，建议多次测试取平均。
• Firefox：Firefox的DevTools里，在「Storage」→「IndexedDB」右键点击数据库选择「Inspect」，能看到更详细的存储统计，包括每个条目的大小。也可以用navigator.storage.estimate() API对比写入前后的存储差值，估算你数据的实际占用。

2. 实际数据表示验证 #

• 数据完整性校验：写入后读取数据，和原始数据做哈希比对是最靠谱的方式：

  // 写入前生成原始数据的哈希
  const originalChunk = new Int8Array(8192);
  // 填充测试数据...
  const originalHash = await crypto.subtle.digest('SHA-256', originalChunk);
  
  // 读取后验证
  const storedChunk = await yourReadFromIDBFunction(); // 替换成你的读取逻辑
  const storedHash = await crypto.subtle.digest('SHA-256', storedChunk);
  console.log('数据是否完整:', crypto.subtle.timingSafeEqual(originalHash, storedHash));
  

• 类型正确性验证：Chromium里能直接看到Int8Array的类型，Firefox显示「Array」只是UI简化，你可以读取后通过storedChunk instanceof Int8Array或者storedChunk.BYTES_PER_ELEMENT === 1来确认类型是否正确。

二、关于存储占用比预期大的问题 #

你遇到的Chrome中40KB数据显示91KB是正常现象：

1. IndexedDB本身有固定开销，比如每个键值对的索引信息、数据库的事务日志、预分配的空闲空间（为了提升写入性能，浏览器会提前分配一些空间）。
2. 你的键是小型数组（路径字符串+数字），这些键本身也会占用存储空间，加上每个8KB块的内部包装开销，累积起来就会让总占用接近你预期的两倍。
3. Chromium的存储统计会把数据库相关的所有文件（比如日志文件）都算进去，所以数值会比实际写入的数据大不少。

Firefox的存储浏览器显示「Array」只是显示层面的问题，实际存储的还是二进制的类型化数组数据，不用太担心。

三、ArrayBuffer vs Int8Array存储的差异 #

从你测试的结果来看，两者存储大小差异极小，原因是：
IndexedDB在存储类型化数组时，本质上存储的是其底层的ArrayBuffer数据，类型化数组只是一个视图。当你存储Int8Array时，浏览器会自动提取它的buffer属性来存储；读取时，会根据存储时记录的类型信息（或者你自己处理）重新创建视图。
两者的差异可能只是浏览器额外记录的类型元数据（标记是Int8Array还是直接的ArrayBuffer），这部分数据非常小，所以占用空间差异可以忽略不计。

实际开发中两种方式都能用：如果需要读取后直接得到Int8Array视图，存储类型化数组更方便；如果只需要二进制数据，存储ArrayBuffer也没问题。

内容的提问来源于stack exchange，提问作者0__