indexedDB在概念上与HTML5本地存储有何不同？

IndexedDB 不是像本地存储那样的键值存储。本地存储只存储字符串，因此要将对象放在本地存储中，通常的方法是JSON.stringify它：

myObject = {a: 1, b: 2, c: 3};
localStorage.setItem("uniq", JSON.stringify(myObject));

这对于查找带有键的对象很好，但是从本地存储中取回myObject的属性的唯一方法是JSON.parse该对象并检查它：uniq

var myStorageObject = JSON.parse(localStorage.getItem("uniq"));
window.alert(myStorageObject.b);

如果本地存储中只有一个或几个对象，则这很好。但是想象一下，你有一千个对象，所有这些对象都有一个属性，并且你想对那些对象做些什么。使用本地存储，您必须遍历整个商店并检查每个项目，这是很多浪费的处理。bb==2b

使用IndexedDB，您可以在值中存储字符串以外的内容：“这包括简单的类型，如DOMString和Date以及Object和Array实例。不仅如此，您还可以对存储在值中的对象的属性创建索引。因此，使用IndexedDb，您可以将相同的一千个对象放入其中，但在属性上创建一个索引，并使用它来检索对象，而无需扫描存储中的每个对象的开销。bb==2

至少这是这个想法。IndexedDB API 不是很直观。

它们似乎在与异步调用相同的线程中运行。这如何不阻止UI？

异步与多线程不是一回事，JavaScript通常不是多线程的。您在JS中执行的任何繁重处理都将阻止UI，如果您想最大程度地减少对UI的阻止，请尝试Web Workers。

indexedDB 允许更大的存储。为什么不增加HTML5商店的大小呢？

因为，如果没有适当的索引，它越大，速度会越慢。

我偶然发现了这篇好文章，讨论了localstorage与indexeddb以及其他可能的选项。

（以下所有值均以毫秒为单位）

https://nolanlawson.com/2015/09/29/indexeddb-websql-localstorage-what-blocks-the-dom/

从文章中总结（完全是作者的观点），

1. 在Chrome，Firefox和Edge的所有三个中，LocalStorage在您写入数据2时完全阻止了DOM。阻塞比内存中的阻塞要明显得多，因为浏览器必须实际刷新到磁盘。
2. 毫不奇怪，由于任何同步代码都会阻塞，因此内存中操作也会阻塞。DOM 在长时间运行的插入期间会阻塞，但除非您处理大量数据，否则您不太可能注意到，因为内存中操作非常快。

3. 在Firefox和Chrome中，IndexedDB在基本键值插入方面都比LocalStorage慢，并且它仍然阻止DOM。在Chrome中，它也比WebSQL慢，WebSQL确实阻止了DOM，但没有那么多。只有在Edge和Safari中，IndexedDB才能设法在不中断UI的情况下在后台运行，更糟糕的是，这两种浏览器仅部分实现了IndexedDB规范。

4. IndexedDB在Web Worker中运行良好，它以大致相同的速度运行，但不会阻塞DOM。唯一的例外是 Safari，它不支持工作线程中的 IndexedDB，但它仍然不会阻止 UI。

5. 如果数据简单且最少，则本地记忆是理想的选择