周末趁没事，就把之前写的一个包重新写了一遍。这个包的作用是为开发者提供更加快捷的indexedDB操作，免除一切烦恼，开箱就用起来。indexedDB是web标准，被大部分现代浏览器完整支持。和localStorage不同的是，indexedDB是真的完整存储js对象的引擎，它甚至支持存储new Date()的值，其他一些基础的js对象类型也可能是支持的。而localStorage是只能存储字符串的，要存储对象，必须通过JSON等进行序列化，而JSON不支持循环嵌套。另外一点就是，localStorage是同步的，indexedDB是异步的。

基于对复杂的indexedDB原生接口进行封装的思路，我发布了hello-indexeddb这个包，可以通过下面这个命令安装

npm install --save hello-indexeddb

完整的文档在github上，可以点击这里阅读。都是key-value数据库，它和localStorage的本质区别在哪里呢？我认为数据库的本质能力是分层检索能力。检索能力对于localStorage简直就是无，它只能通过一个key得到一个value，而且是字符串的。而indexedDB可以通过创建索引进行检索，查询某个object的时候，可以通过主键快速get，也可以通过索引来快速query，这里的索引在代码层面就是一个被记录的object的属性。这看上去好像也没什么，比如我可以通过构造多种变形的key来保存localStorage，然后自己封装一套检索方法来进行查询，甚至我自己构建一套localStorage的索引来快速查询。这当然是可以的，从这点上来讲，indexedDB甚至没有localStorage有优势，因为localStorage是同步的，更直观，而且不会出现事件循环错误，也就不需要事务机制。但是同步有同步的坏处，那就是阻塞页面进程。

读完stackoverflow上的这个讨论后我更加确信localStorage是有局限的，也就是说，它真的真的仅仅适合那些非常小、碎片化的数据存储，而indexedDB才是完整的长久存储数据的解决方案。这也就是说，在一个web应用中，应该合理的选择使用localStorage还是indexedDB。大家之所以那么青睐使用localSotrage，最大的原因莫过于它的接口太过简单了。不过想要让indexedDB变得简单也非常容易，就是使用我上面的包。你甚至可以这么用：

async function() {
  let idb = new HelloIndexedDB({ key: 'key' })
  await idb.put({ key: 'my_key', value: 'my_value' })
  let obj = await idb.get('my_key')
}

就是这么简单，跟localStorage相比，就是异步和同步的区别。在对put这个操作的适合，转换一下localStorage里面的set操作的思维，然后，就非常自然的切换到了indexedDB的怀抱里面。要知道，get回来的，是一个拥有上下文的真实的js对象，而非字符串序列化和反序列化的结果。

就这样，拥抱indexedDB吧～