隨著前端技術(shù)日新月異地快速發(fā)展，web應(yīng)用功能和體驗(yàn)也逐漸發(fā)展到可以和原生應(yīng)用媲美的程度，前端緩存技術(shù)的應(yīng)用對(duì)這起到了不可磨滅的貢獻(xiàn)，因此想一探前端的緩存技術(shù)，這篇文章主要會(huì)介紹在日常開發(fā)中比較少接觸的IndexedDB

IndexedDB簡(jiǎn)單理解就是前端數(shù)據(jù)庫(kù)，提供了一種在用戶瀏覽器中持久存儲(chǔ)數(shù)據(jù)的方法，但是和前端關(guān)系型數(shù)據(jù)不同的是，IndexedDB采用的key-value鍵值對(duì)存儲(chǔ)，這種存儲(chǔ)形式的數(shù)據(jù)庫(kù)查詢更簡(jiǎn)單快速，IndexedDB分別為同步和異步訪問(wèn)提供了多帶帶的API，但是同步API僅提供在web worker內(nèi)部使用，因此絕大多數(shù)情況，我們使用的都是異步API，同時(shí)IndexedDB也無(wú)法突破同源策略的限制，只能訪問(wèn)在同域下的數(shù)據(jù)

提到為什么要用IndexedDB就不得不提到我們經(jīng)常用的緩存API localStorage和sessionStorage，這兩個(gè)緩存API能滿足我們開發(fā)時(shí)的絕大多數(shù)需求，簡(jiǎn)單的鍵值存儲(chǔ)，但是它們有它們的限制：

存儲(chǔ)空間限制，只有5M

只能存儲(chǔ)字符串，存儲(chǔ)對(duì)象類型的數(shù)據(jù)要用JSON.stringify和parse兩個(gè)方法轉(zhuǎn)換

存儲(chǔ)的字段一多就很難管理，存儲(chǔ)的字段也無(wú)法產(chǎn)生關(guān)聯(lián)

IndexedDB的存儲(chǔ)空間是沒(méi)有限制，但是不同瀏覽器可能會(huì)對(duì)IndexedDB中單個(gè)庫(kù)的大小進(jìn)行一定的限制，IndexedDB本質(zhì)上還是一個(gè)數(shù)據(jù)庫(kù)，可以存儲(chǔ)大量結(jié)構(gòu)化數(shù)據(jù)（包括文件/blobs）,同時(shí)IndexedDB API通過(guò)索引的方式實(shí)現(xiàn)了數(shù)據(jù)的高性能搜索

前面介紹一堆IndexedDB相關(guān)的內(nèi)容，接下來(lái)就來(lái)看看具體IndexedDB具體怎么使用，以一個(gè)簡(jiǎn)單的例子來(lái)切入，下面直接上具體代碼：

var data = [{
  id: 1,
  name: "Tom",
  age: "18"  
}, {
  id: 2,  
  name: "Tommy",
  age: "16"
}]  
// 打開數(shù)據(jù)庫(kù)，兩個(gè)參數(shù)（數(shù)據(jù)庫(kù)名字，版本號(hào)），如果數(shù)據(jù)庫(kù)不存在則創(chuàng)建一個(gè)新的庫(kù)
var request = window.indexedDB.open("myDatabase", "1")
// 數(shù)據(jù)庫(kù)操作過(guò)程中出錯(cuò)，則錯(cuò)誤回調(diào)被觸發(fā)
request.onerror = (event) => {
  console.log(event)
}
// 數(shù)據(jù)庫(kù)操作一切正常，所有操作后觸發(fā)
request.onsuccess = (event) => {
  var db = event.target.result
  // 數(shù)據(jù)讀取
  var usersObjectStore = db.transaction("users").objectStore("users")
  var userRequest = usersObjectStore.get(1)
  userRequest.onsuccess = function (event) {
    console.log(event.target.result)
  }
}
// 創(chuàng)建一個(gè)新的數(shù)據(jù)庫(kù)或者修改數(shù)據(jù)庫(kù)版本號(hào)時(shí)觸發(fā)
request.onupgradeneeded = (event) => {
  var db = event.target.result
  // 創(chuàng)建對(duì)象倉(cāng)庫(kù)用來(lái)存儲(chǔ)數(shù)據(jù)，把id作為keyPath，keyPath必須保證不重復(fù)，相當(dāng)于數(shù)據(jù)庫(kù)的主鍵
  var objectStore = db.createObjectStore("users", { keyPath: "id"})
  // 建立索引，name和age可能重復(fù)，因此unique設(shè)置為false
  objectStore.createIndex("name", "name", {unique: false})
  objectStore.createIndex("age", "age", {unique: false})
  // 確保在插入數(shù)據(jù)前對(duì)象倉(cāng)庫(kù)已經(jīng)建立
  objectStore.transaction.oncomplete = () => {
    // 將數(shù)據(jù)保存到數(shù)據(jù)倉(cāng)庫(kù)
    var usersObjectStore = db.transaction("users", "readwrite").objectStore("users")
    data.forEach(data => {
      usersObjectStore.add(data)
    })
  }
}

上面的例子介紹了IndexedDB的簡(jiǎn)單用法，當(dāng)執(zhí)行完上面的代碼后可以在瀏覽器中看到自己新建的IndexedDB:

考慮到不是所有人都會(huì)將IndexedDB應(yīng)用于實(shí)際工作，因此上面只是介紹了簡(jiǎn)單API的調(diào)用，更多關(guān)于IndexedDB的用法可以去MDN學(xué)習(xí)，真正需要使用的時(shí)候，對(duì)于其異步API調(diào)用如果不做一定的封裝，一定會(huì)陷入深深的回調(diào)地獄，因此這里推薦兩個(gè)IndexedDB API的封裝庫(kù):

Dexie.js

localForage

相信這個(gè)話題應(yīng)該是大部分人最感興趣的，IndexedDB到底應(yīng)用在什么地方？前面介紹了這么多，IndexedDB使用比localStorage、sessionStorage復(fù)雜得多，如果沒(méi)有特定的使用場(chǎng)景，開發(fā)者一定不會(huì)自己給自己找麻煩選擇IndexedDB做緩存，結(jié)下就來(lái)看看IndexedDB適用的場(chǎng)景：

不需要網(wǎng)絡(luò)連接的純離線應(yīng)用，比如Todolist這類的用來(lái)記錄待辦任務(wù)類型的應(yīng)用，

在不考慮需要聯(lián)網(wǎng)的登錄、分享功能下，待辦事項(xiàng)、收件箱、任務(wù)核心功能完全可以用IndexedDB做數(shù)據(jù)庫(kù)存儲(chǔ)，配合Electron做一個(gè)桌面應(yīng)用

需要存儲(chǔ)大量數(shù)據(jù)的應(yīng)用，比如圖書管理系統(tǒng)這類的需要存儲(chǔ)大量數(shù)據(jù)的應(yīng)用，完全可以將圖書信息存儲(chǔ)在IndexedDB中

配和service worker構(gòu)建pwa應(yīng)用，用來(lái)緩存網(wǎng)絡(luò)請(qǐng)求

這篇文章簡(jiǎn)單介紹了IndexedDB的相關(guān)內(nèi)容，總的來(lái)說(shuō)，IndexedDB的應(yīng)用頻率并不高，這是由于IndexedDB適用復(fù)雜度和不多的適用場(chǎng)景決定的，因此這里也只是對(duì)它做了簡(jiǎn)單介紹，希望看了這篇文章后，能對(duì)IndexedDB有個(gè)簡(jiǎn)單的了解，在需要使用的時(shí)候能有個(gè)印象。如果有錯(cuò)誤或不嚴(yán)謹(jǐn)?shù)牡胤?，歡迎批評(píng)指正，如果喜歡，歡迎點(diǎn)贊