【前言】
首先如标题所说，这4个东西都是和前端存储有关的。由于HTTP是一个无状态协议，那么在实际应用场景中有时候server端需要知道些客户端的信息（比如是否登录了，权限问题等等），这个时候上述4个存储api就应运而生了。
【cookie】
1. 存储上限：4kb。
2. 特点：每次http传输都会被自动带上，在secure字段设置为true的时候，只有当前地址才能读取。server端设置http-only，那么js就无法操作cookie了。
3. 有效期：默认tab页关闭后就失效了，可以通过expire设置。
4. 作用域：由domain和path确定。具体规则是domain是当前域名或者当前域名的父域名，当前path或者当前path的父path
5. 存储的地方：虽然我们能在请求头中拿到cookie，其本质应该还是存在硬盘中的。
6. 应用场景：每次信息处理都需要和server端交互的情景。
7. 缺点：存储量少，操作麻烦，增加传输负担。
【sessionStorage】
1. 存储上限：5~10mb左右，不同厂商略有差异。
2. 特点：关闭tab页就没了，没有做持久化， 同步操作。
3. 有效期：关闭tab页就没了。
4. 作用域：同源（同端口，同域名，同协议）。
5. 存储的地方：应该是内存中，但是存取速度还是非常的慢，测量了一次存1mb的数据需要半小时）。
6. 应用场景：不需要做持久化，少量数据处理不用每次都和后端交互的情况。
7. 缺点：存储量较少，性能随着容量减小显著下降，不同项目都存在一起，维护困难，只能保存字符串。
【localStorage】
1. 存储上限：5~10mb左右，不同厂商略有差异。
2. 特点：持久化, 同源文档不同tab页可以信息共享甚至监听修改，同步操作。
3. 有效期：不删除就永久存在。
4. 作用域：同源（同端口，同域名，同协议）。
5. 存储的地方：硬盘。
6. 应用场景：需要做持久化，少量数据处理不用每次都和后端交互的情况。
7. 缺点：存储量较少，性能随着容量减小显著下降, 不同项目都存在一起，维护困难，只能保存字符串。
【indexDB】
1. 存储上限：基本无限，不同厂商略有差异。
2. 特点：持久化，同域名下不同项目可以创建不同的数据库供自己使用，异步操作，能保存二进制（blob）的数据。
3. 有效期：不删除就永久存在。
4. 作用域：同源（同端口，同域名，同协议）。
5. 存储的地方：硬盘。
6. 应用场景：需要做持久化，大量数据处理不用每次都和后端交互的情况。
7. 缺点：性能随着数据变多不会显著下降（2.5mb的数据，虽然没有精确计算，但至少半小时内，但是webStorage,2小时过去了还是没好）。
常见问题解决：
很多公司经常把几条业务线都挂在同一个域名下，比如a.com/a.html和a.com/b.html。长此以往就会出现localstorage不够用的情况。（现象就是报错（和sessionstorage一样）DOMException——谷歌81）
解决方案：
- 对localstorage进行划分，出具相关规范。
- 直接用indexDB替代
【后记】
由于原生indexDB的API还是很基础的，无法满足实际生产需要，网上搜了下，也没有公认的最好的解决方案，所以自己干脆自己写了一个indexDB工具库。
github：github.com/michael2010…
gitee(国内镜像):gitee.com/iwangcx/ind…
