放弃localStorage,拥抱IndexedDB
不知道为何文章被知乎说非法转载，只好重新再修改一次发了，哈哈。
概述
随着前端的技术发展越来越强，网页功能不断增加，越来越复杂的交互和业务需要前端来实现，那么作为前端开发就需要面对越来越庞大的数据体，那么其中一个常用的优化方式就是本地存储一些不变的数据，从而提升页面渲染的速度，减少从服务器获取数据。
我们以前和现在都会经常用的本地缓存方式一般都是localStorage、sessionStorage和cookie。但是都会有一个很严重的问题，就是它们都不能存放大量数据，在现在的业务情况下，很容易出现存放数据过大，导致超出浏览器对于localStorage、sessionStorage和cookie的存储大小，cookie不能超过4KB，localStorage和sessionStorage一般不超过4MB（不同浏览器的限制不一样），所以这些技术都不太适合存放大量的数据。所以在这个前提下，我们就可以使用HTML5提供的新API，IndexedDB!
IndexedDB 具有以下特点。
- key/value的存储方式：IndexedDB和localStorage的存储方式很类似，都是通过一个key对应一个value，而且key是唯一的方式进行存储的，但是indexedDB和localStorage有很不一样的一点，就是可以直接存储对象数组等，不需要想localStorage那样必须转为字符串。
- 异步调用：IndexedDB是使用异步调用的，当我们存储一个较大的数据时，不会因为写入数据慢而导致页面阻塞。
- 支持事务：IndexedDB支持事务，如果有用过mysql和mongoDB的人就很清楚了，能确保我们多个操作只要其中一步出现问题，可以整体回滚。
- 同源限制：IndexedDB和localStorage一样，都是有同源策略的问题，不能跨协议、端口、域名使用。
- 储存空间：IndexedDB我认为最最最大的优势在于存储空间相比localStorage要大得多，一般来说不少于250MB。
- 支持二进制：IndexedDB不但可以存储对象，字符串等，还可以存储二进制数据。
兼容
我们通过caniuse来看看兼容情况。
可以看到大部分主流程的浏览器其实都已经兼容了indexedDB了，那么我们只需要做一些简单的降级就可以了。
如何使用
IndexedDB其实网上有很多教程，可以直接看MDN或者自行Google。在这里不就重复去说明了，如果你有用过mongoDB的话，那么也很好理解IndexedDB的原理和使用。
什么场景下使用
其实无论是你要存储大量的数据到本地，还是小量数据到本地，其实都可以使用IndexedDB。那么我是什么情况下用呢？
最近在公司有一个场景，就是对我们的商品列表的数据进行缓存，因为在浏览器当中，如果要实现后退上一个页面，不刷新页面，一般只有用单页应用才能实现，但是无奈我们因为种种原因，没有使用单页，所以必须要将数据缓存到本地，下次打开列表后，发现如果url中的id和缓存的数据id一致，那么就直接使用缓存数据，不再进行请求。
一开始打算就用localStorage来解决的，但是发现在一些特定情况下，数据有可能达到接近5MB的数据，在PC的Chorme中是可以存到localStorage的，但是在IOS中，却报出空间不足，无法放入localStorage中，所以这个时候就是使用indexedDB了！因为indexedDB的空间大得我可以完全不去考虑数据大小，而且还能直接以对象的形式存入，无需转为JSON字符串。大大减少了转换的运算。但是因为使用indexedDB和使用localStorage是完全不一样的，基本上都是异步操作而且还要考虑一些低版本的手机可能不支持的情况，所以要封装中间件，同样的调用，根据设备对indexedDB的兼容情况，自动决定使用indexedDB还是localStorage。最终完成需求，并且优化前后达到超过70%的优化率，页面的渲染基本秒开。
总结
indexedDB是完全可以替代localStorage的存在，而且为了以后更加方便的使用indexedDB，让indexedDB的api兼容同步调用，以及更像localStorage的使用，特地封装了一个well-cache的库，希望大家多多支持，也可以为我提提优化的建议。谢谢！