前言

在项目开发过程中，前端需要存储大量的数据。cookie, localstorage 都有存储长度限制。

表格一览

特性cookielocalStoragesessionStorageindexedDB
数据生命周期一般由服务器生成，可以设置过期时间；前端采用和 js-cookie 等组件也可以生成除非被清理，否则一直存在；浏览器关闭还会保存在本地，但是不支持跨浏览器页面关闭就清理刷新依然存在，不支持跨页面交互除非被清理，否则一直存在
数据存储大小4K5M5M不限制大小
与服务端通信每次都会携带在请求的 header 中，对于请求性能有影响；同时由于请求中都带有，所以也容易出现安全问题不参与不参与不参与
特点字符串键值对在本地存储数据字符串键值对在本地存储数据字符串键值对在本地存储数据IndexedDB 是一个非关系型数据库（不支持通过 SQL 语句操作）。可以存储大量数据，提供接口来查询，还可以建立索引，这些都是其他存储方案无法提供的能力。

需要一个存储容量大，支持搜索和自定义索引的前端存储方案，就选用了 。
caniuse 上查看 indexedDB 支持情况，目前浏览器支持情况良好。
https://caniuse.com/?search=indexedDB

IndexedDB 介绍

IndexedDB 属于非关系型数据库。（不支持 SQL 查询）

特点：

  • 键值对储存 IndexedDB 内部采用对象仓库（object store）存放数据。所有类型的数据都可以直接存入，包括 JavaScript 对象。对象仓库中，数据以"键值对"的形式保存，每一个数据记录都有对应的主键，主键是独一无二的，不能有重复，否则会抛出一个错误。
  • 异步 IndexedDB 操作时不会锁死浏览器，用户依然可以进行其他操作，这与 LocalStorage 形成对比，后者的操作是同步的。异步设计是为了防止大量数据的读写，拖慢网页的表现。
  • 支持事务 IndexedDB 支持事务（transaction），这意味着一系列操作步骤之中，只要有一步失败，整个事务就都取消，数据库回滚到事务发生之前的状态，不存在只改写一部分数据的情况。
  • 同源限制 IndexedDB 受到同源限制，每一个数据库对应创建它的域名。网页只能访问自身域名下的数据库，而不能访问跨域的数据库。
  • 支持二进制储存 IndexedDB 不仅可以储存字符串，还可以储存二进制数据（ArrayBuffer 对象和 Blob 对象。
  • 储存空间大 IndexedDB 的储存空间比 LocalStorage 大得多，一般来说不少于 250MB，甚至没有上限。储 存 在 电 脑 上 中 的 位 置 为 C:\Users\当 前 的 登 录 用 户\AppData\Local\Google\Chrome\User Data\Default\IndexedDB

核心概念

  • 数据库：IDBDatabase 对象，数据库有版本概念，同一时刻只能有一个版本，每个域名可以建多个数据库
  • 对象仓库：IDBObjectStore 对象，类似于关系型数据库的表格
  • 索引： IDBIndex 对象，可以在对象仓库中，为不同的属性建立索引，主键建立默认索引
  • 事务： IDBTransaction 对象，增删改查都需要通过事务来完成，事务对象提供了 error,abord,complete 三个回调方法，监听操作结果
  • 操作请求：IDBRequest 对象
  • 指针： IDBCursor 对象
  • 主键集合：IDBKeyRange 对象，主键是默认建立索引的属性，可以取当前层级的某个属性，也可以指定下一层对象的属性，还可以是一个递增的整数

一些封装好的库

  1. localforage 推荐 ⭐️⭐️⭐️⭐️⭐️
  2. IndexedDBWrapper 推荐 ⭐️⭐️⭐️

思考我们还可以用 indexedDB 做什么

1. 用户使用日志收集

在做一些前端electron应用，webApp,我们可以定义一个log日志库，来收集用户日志，遇到问题时，可以让用户，打包上传到日志库，排查跟进解决用户反馈问题。

导出所有数据，并上传
此处就可以用上面的 getAll 方法，获取该表所有数据，生成 json 打包上传到自己公司的日志库。

2. request 层封装，对不长更新接口缓存

封装 request 方法，缓存请求接口，物理缓存数据~让页面接口数据加载飞起来

3. 大文件上传，分片，避免网络失败，刷新页面等导致中断问题

文件切片后先存储到indexedDB库，动态更新上传状态，异常状况可取出再继续定位到未上传的切片继续上传

问题

  1. 如果用户使用 ie 浏览器，请问阁下该如何应对？
  2. 用户：请不要在我的硬盘里面拉屎
  3. 什么情况下，会需要前端存储大量数据？请提供一个完整的使用场景
  4. indexdb 读取数据比较慢，性能差点意思
    .....

总结

indexDB 是个好东西，n 年前就在用，但是基于以下场景，不得不放弃它，它再好那也只能是个鸡肋。

  1. PC 端浏览器内核目前市场上太多，版本都是各式各样的，兼容性很难满足；
  2. 移动端如此横行的时代，各个手机的浏览器版本其实对它的支持也是个问题；
  3. 为了降本，很多企业都流行混合开发，基于市场的很多框架，这不得不使 indexDB 又被抛弃了；
  4. 虽然比 localstorage 强大，但是学习成本和使用成本比 localstorage 要高，这使得很多开发者望而止步；
  5. 前端在一般的业务中很少会存储本地数据大于 5M 的场景；
  6. 要存那么多数据在本地，为何不直接劳烦后端去建一张表存储，这无非又给前端加了一条背锅的理由；
  • 最后总结：如果实在！实在！实在！是数据量非常的大，还是建议前端学习一下 nodejs 和数据库相关的知识，这样既实现了功能需求，又能学到非鸡肋的知识。