我们正面临一个问题
当我们尝试打开索引数据时，没有触发回调
我们正在执行以下步骤：
1.使用以下步骤打开数据库：
request = indexedDB.open(name, 10);
request.onerror = onError;
request.onsuccess = onSuccess;
request.onupgradeneeded = onUpgradeNeeded;
request.onblocked=onBlocked;<br>
2.注意没有触发任何回调 3.open chrome：// indexeddb-internals /＃，它显示上一个删除数据库正在等待。
答案 0 :(得分：1)
您可能打开了另一个与数据库连接的选项卡。
打开/删除请求进入队列。没有指定版本（或指定与当前数据库相同的版本）的打开请求可以在到达队列前面时立即处理。对更高版本的打开请求或到达队列前面的删除请求必须等待所有其他连接关闭。如果他们在收到＆＃34;版本更改后立即关闭＆＃34;然后请求继续。如果没有，请求会被阻止＆＃34;事件并等待连接关闭。
请注意，队列中的其他请求不会获取事件 - 他们只是等到他们到达队列的前面并被处理或被阻止＆＃34;
在第3步中，您报告有先前的删除请求待处理。这表明它被封锁了;据推测，还有另一个连接。因此，删除请求位于队列的前面，并且“＃34;阻止＆＃34;”，并且您的打开请求（对于版本10）位于队列后面，并且（如您所知）它不会被取消看到事件，直到它到达队列的前面。
答案 1 :(得分：0)
尽管Joshua Bell的回答是正确的，但我想添加（基于他的回答：），它的blocked = upgradeBlocked（仅当您具有保持连接打开策略并且您的应用程序在1个以上的选项卡中打开且您尝试升级选项卡中的架构，但是另一个选项卡中的其他打开的连接不会在版本更改事件上关闭，该版本更改事件也会触发...因此升级被阻止），您的代码似乎被阻塞了，但是您没有监听器那个。
我本人对请求实施了超时，因此我始终知道在超时范围内提供超时，成功，升级成功或错误触发。我以为封锁永远不会发生，因为我总是在versionchange上关闭连接。
但是我想当然好的代码通常不会面临超时。因此，这是用于完美的运行时处理。如果您经常遇到超时，则问题的根源可能在其他地方。因此，拥有onBlockedUpgrade和onBlockedQueue并不会真正有帮助。建立像xhr这样的超时机制将是很棒的：）
但是很高兴知道约书亚·贝尔（Joshua Bell）的“排队问题” ：）您最好实现超时，并且在此具体情况下，您应该在其他地方找到问题。