IndexedDB压力测试需验证真实业务负载下的稳定性，重点监测单次查询延迟、连续读取吞吐量和内存增长趋势；数据规模应贴近实际（如50万条日志则用80万条含时间戳、文本、小Blob的真实数据）；批量写入须用单事务多记录、建multiEntry索引、分离大对象存储，并等待transaction.oncomplete再启动读取测试；读取场景覆盖随机key并发get、范围游标遍历、时间索引查询，全程监控JS Heap与Detached DOM trees；通过StorageManager.estimate()检查配额余量，超85%时需分库或归档。
明确测试目标与数据规模
IndexedDB 压力测试不是单纯“跑快慢”，而是验证在真实业务负载下是否稳定可用。重点观察三项指标：单次查询延迟、连续读取吞吐量（如每秒读取记录数）、内存占用增长趋势。数据量需贴近实际场景——比如你的应用预计存储 50 万条日志，测试就应准备至少 80 万条结构一致的数据，且包含典型字段（如时间戳、文本内容、小 Blob），避免用空对象或纯数字填充，否则无法暴露序列化/反序列化瓶颈。
构造真实数据并控制事务粒度
批量写入阶段就要为后续读取压力测试打基础：
- 使用 单个事务写入多条记录（例如每次 transaction.objectStore('logs').add() 连续调用 100 次），而不是每条记录开一个事务，大幅降低开销；
- 为高频查询字段（如
timestamp）建立 multiEntry 索引，支持范围查询（IDBKeyRange.lowerBound()）； - 避免在写入时嵌套大对象（如完整音频 ArrayBuffer 或长 Base64 字符串），可改用分离存储策略（主表存 ID，另建 store 存二进制）；
- 写入完成后主动调用
transaction.oncomplete确保索引构建完成，再开始读取测试。
模拟典型读取场景并监控资源
不要只测“全表扫描”，要覆盖常见模式：
-
随机主键读取：从 50 万条中随机选 1000 个 key，用
get()并发请求（Promise.all），观察平均延迟和失败率； -
范围游标遍历：用
openCursor(IDBKeyRange.bound(start, end))读取连续 1 万条，注意检查cursor.continue()是否被阻断、事务是否提前关闭； - 索引查询：按时间范围查最新 100 条，确认索引命中而非全表扫描（可通过 DevTools 的 Application → IndexedDB 面板查看对象存储大小变化辅助判断）；
- 全程开启 Chrome DevTools 的 Memory 面板录制，重点关注“JS Heap”和“Detached DOM trees”增长，若某次游标迭代后堆内存突增且不回落，大概率是闭包意外持有
cursor.value引用。
利用 StorageManager API 评估配额余量
大容量读取可能触发浏览器配额限制，尤其在无痕模式下（Chrome 无痕模式配额常不足 2GB）：
- 运行以下代码获取实时空间状态：
if ('storage' in navigator && 'estimate' in navigator.storage) {
navigator.storage.estimate().then(estimate => {
console.log('已用:', (estimate.usage / 1e9).toFixed(2), 'GB');
console.log('总额度:', (estimate.quota / 1e9).toFixed(2), 'GB');
});
} - 若已用占比超 85%，读取性能可能因底层磁盘碎片或垃圾回收频繁而下降，此时应考虑分库或定期归档旧数据；
- 注意：StorageManager 返回的是估算值，不同浏览器策略差异大，Firefox 通常比 Chrome 更保守。
