IndexedDB调用databases()获取数据库列表偶发1分钟延迟的排查求助

• Chrome的IndexedDB锁机制差异：Chrome中indexedDB.databases()需要获取数据库元数据的读取锁，跨上下文（主线程、Web Worker、Service Worker）的IndexedDB操作会持有不同级别的锁，哪怕是小事务也可能导致databases()等待锁释放。Firefox的锁调度逻辑更宽松，不会出现这类长时间等待。
• Service Worker后台操作阻塞：如果Service Worker在后台执行周期性的IndexedDB同步（比如缓存更新），刚好和databases()调用撞车，Chrome会优先处理SW的操作（或存在锁竞争），导致主线程的databases()被长时间阻塞。
• Dexie未释放的事务：Dexie会维护IndexedDB连接池，若Web Worker或主线程中存在未正确提交/回滚的事务（比如遗漏await、异常未捕获导致事务挂起），会持续持有锁，使得databases()无法读取元数据。
• Chrome元数据缓存失效：当Chrome的IndexedDB元数据缓存损坏时，databases()会直接遍历磁盘上的数据库文件，若此时系统磁盘IO繁忙（如Mac Spotlight索引、Windows Defender扫描），就会出现长达1分钟的延迟，Firefox的元数据缓存机制不会触发这类磁盘遍历。

• 排查跨上下文锁竞争：
  • 打开Chrome DevTools的Application > IndexedDB面板，切换到所有上下文（主线程、Web Worker、Service Worker），查看是否有活跃的未完成事务；
  • 用Performance面板录制完整流程，筛选IndexedDB事件，查看databases()调用前后是否有锁等待的标记（如IndexedDB: wait for lock）。
• 验证Service Worker的影响：
  • 在Service Worker的Dexie操作代码中添加日志，记录操作的开始/结束时间，对比databases()延迟的时间点；
  • 临时禁用Service Worker（在DevTools的Application > Service Workers中勾选Bypass for network），测试databases()是否还会出现延迟。
• 检查Dexie事务完整性：
  • 确保所有Dexie事务都用await等待完成，或者在finally块中手动关闭；
  • 监听Dexie的transactioncomplete和transactionabort事件，记录所有事务的状态，排查是否有挂起的事务：

    db.on('transactioncomplete', (tx) => console.log('事务完成:', tx.tableNames));
    db.on('transactionabort', (err) => console.error('事务中止:', err));
    

• 检查IndexedDB元数据状态：
  • 访问chrome://indexeddb-internals/，查看数据库列表是否有异常条目，比如状态为corrupted的数据库；
  • 清除应用的IndexedDB数据（DevToolsApplication > Storage > Clear site data），重新初始化应用，看延迟是否消失。
• 排查系统磁盘IO：
  • 延迟发生时，查看系统磁盘占用率（Mac用Activity Monitor，Windows用任务管理器），确认是否有其他进程在占用磁盘资源。

内容的提问来源于stack exchange，提问作者George Chernov