摘要：字節(jié)流這個(gè)簡單的模型將數(shù)據(jù)存儲(chǔ)為長度不透明的字節(jié)字符串變量，將任何形式的內(nèi)部組織留給應(yīng)用層。字節(jié)流數(shù)據(jù)存儲(chǔ)的代表例子包括文件系統(tǒng)和云存儲(chǔ)服務(wù)。使用同步存儲(chǔ)會(huì)阻塞主線程，并為應(yīng)用程序的創(chuàng)建凍結(jié)體驗(yàn)。

這是專門探索 JavaScript 及其所構(gòu)建的組件的系列文章的第 16 篇。

想閱讀更多優(yōu)質(zhì)文章請猛戳GitHub博客,一年百來篇優(yōu)質(zhì)文章等著你！

如果你錯(cuò)過了前面的章節(jié)，可以在這里找到它們：

JavaScript 是如何工作的：引擎，運(yùn)行時(shí)和調(diào)用堆棧的概述！

JavaScript 是如何工作的：深入V8引擎&編寫優(yōu)化代碼的5個(gè)技巧！

JavaScript 是如何工作的：內(nèi)存管理+如何處理4個(gè)常見的內(nèi)存泄漏！

JavaScript 是如何工作的：事件循環(huán)和異步編程的崛起+ 5種使用 async/await 更好地編碼方式！

JavaScript 是如何工作的：深入探索 websocket 和HTTP/2與SSE +如何選擇正確的路徑！

JavaScript 是如何工作的：與 WebAssembly比較 及其使用場景！

JavaScript 是如何工作的：Web Workers的構(gòu)建塊+ 5個(gè)使用他們的場景!

JavaScript 是如何工作的：Service Worker 的生命周期及使用場景!

JavaScript 是如何工作的：Web 推送通知的機(jī)制!

JavaScript是如何工作的：使用 MutationObserver 跟蹤 DOM 的變化!

JavaScript是如何工作的：渲染引擎和優(yōu)化其性能的技巧!

JavaScript是如何工作的：深入網(wǎng)絡(luò)層 + 如何優(yōu)化性能和安全!

JavaScript是如何工作的：CSS 和 JS 動(dòng)畫底層原理及如何優(yōu)化它們的性能！

JavaScript的如何工作的：解析、抽象語法樹（AST）+ 提升編譯速度5個(gè)技巧!

JavaScript是如何工作的：深入類和繼承內(nèi)部原理+Babel和 TypeScript 之間轉(zhuǎn)換!

在設(shè)計(jì) Web 應(yīng)用程序時(shí)，為本地瀏覽器選擇合適的存儲(chǔ)機(jī)制至關(guān)重要， 一個(gè)好的存儲(chǔ)引擎可以確?？煽康乇４嫘畔?，減少帶寬，提高響應(yīng)能力。正確的存儲(chǔ)緩存策略是實(shí)現(xiàn)離線移動(dòng) Web 體驗(yàn)的核心構(gòu)建塊，同時(shí)也大大的提高了用戶體驗(yàn)。

在本章中，討論可選擇的存儲(chǔ) Api 和服務(wù)，并提供一些在構(gòu)建 Web應(yīng)用程序，該使用哪種存儲(chǔ)引擎。

數(shù)據(jù)存儲(chǔ)模型確定數(shù)據(jù)在內(nèi)部的組織方式,這會(huì)影響 Web 應(yīng)用程序的整個(gè)設(shè)計(jì)，合理的數(shù)據(jù)模式會(huì)讓 Web 應(yīng)用程序在完成它應(yīng)有的任務(wù)下還能讓運(yùn)行速度更加高效。對于所有與工程相關(guān)的問題，沒有存在最好的解決方法，也沒有適用于所有問題的解決方案，不同場景下有不同的選擇。所以，來看看可選擇的數(shù)據(jù)模型:

結(jié)構(gòu)化: 存儲(chǔ)在具有預(yù)定義字段的表中的數(shù)據(jù)(這是典型的基于 SQL 的數(shù)據(jù)庫管理系統(tǒng))適行靈活的動(dòng)態(tài)查詢。瀏覽器中結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)的一個(gè)代表的例子是 IndexedDB。

Key/Value: 鍵/值 數(shù)據(jù)存儲(chǔ)和相關(guān)的 NoSQL 數(shù)據(jù)庫提供了存儲(chǔ)和檢索由唯一鍵索引的非結(jié)構(gòu)化數(shù)據(jù)的能力。鍵/值 數(shù)據(jù)存儲(chǔ)類似于哈希表，因?yàn)樗鼈冊试S對索引的不透明數(shù)據(jù)進(jìn)行長時(shí)間訪問。 鍵/值 數(shù)據(jù)存儲(chǔ)的代表例子是瀏覽器中的 Cache API 和服務(wù)器上的 Apache Cassandra。

Apache Cassandra 是一套開源分布式數(shù)據(jù)庫管理系統(tǒng)，由Facebook開發(fā)，用于儲(chǔ)存特別大的數(shù)據(jù)。

字節(jié)流：這個(gè)簡單的模型將數(shù)據(jù)存儲(chǔ)為長度不透明的字節(jié)字符串變量，將任何形式的內(nèi)部組織留給應(yīng)用層。這個(gè)模型特別適合于文件系統(tǒng)和其他分層組織的數(shù)據(jù)塊。字節(jié)流數(shù)據(jù)存儲(chǔ)的代表例子包括文件系統(tǒng)和云存儲(chǔ)服務(wù)。

web 應(yīng)用程序的存儲(chǔ)方法可以根據(jù)數(shù)據(jù)持久化的時(shí)間段進(jìn)行劃分：

會(huì)話持久化： 該類別中的數(shù)據(jù)僅在單個(gè) Web 會(huì)話或?yàn)g覽器選項(xiàng)卡保持激活狀態(tài)時(shí)才持久，具有會(huì)話持久性的存儲(chǔ)機(jī)制的一個(gè)示例是 Session Storage API。

設(shè)備的持久化： 此類別中的數(shù)據(jù)在特定設(shè)備上跨會(huì)話和瀏覽器選項(xiàng)卡/窗口持久化，具有設(shè)備持久化的存儲(chǔ)機(jī)制的一個(gè)示例是 Cache API。

此類中的數(shù)據(jù)跨會(huì)話和設(shè)備持久化。因此，它是最健壯的數(shù)據(jù)持久性形式。但是，它不能存儲(chǔ)在設(shè)備本身上，這意味需要在某種服務(wù)器端存儲(chǔ)。在這里不會(huì)詳細(xì)討論它，因?yàn)楸疚牡闹攸c(diǎn)是在設(shè)備本身上存儲(chǔ)數(shù)據(jù)。

現(xiàn)在，有相當(dāng)多的瀏覽器 Api 用來存儲(chǔ)數(shù)據(jù)。這里將逐一介紹其中的一些及它們的區(qū)別，以便后續(xù)我們能夠容合理的選擇使用。

然而，在選擇如何持久化數(shù)據(jù)之前，有幾件事需要考慮。當(dāng)然，有必要知道的的第一件事是你的 Web 應(yīng)用程序應(yīng)用場景是什么，以及以后如何迭代和豐富。即使你知道了這些，最終也會(huì)有幾個(gè)選擇。所以，以下是需要了解的：

瀏覽器支持 ?—? 標(biāo)準(zhǔn)化和完善的 API 更值得我們選擇，因?yàn)樗鼈兺鶋勖L，支持更廣泛， 這些API 還享有更豐富的文檔和開發(fā)人員社區(qū)。

事務(wù) —?有時(shí)，相關(guān)存儲(chǔ)操作的集合原子地成功或失敗是很重要的。傳統(tǒng)上，數(shù)據(jù)庫使用事務(wù)模型支持此功能，其中相關(guān)更新可以分組到任意單元中。

同步/異步 — 有些存儲(chǔ) Api 是同步的，因?yàn)榇鎯?chǔ)或檢索請求會(huì)阻塞當(dāng)前活動(dòng)的線程，直到請求完成。使用同步存儲(chǔ) API 會(huì)阻塞主線程，并為 Web 應(yīng)用程序的 UI 創(chuàng)建凍結(jié)體驗(yàn)。如果可能，使用異步API。

在本節(jié)中，了解決 Web 開發(fā)人員的當(dāng)前可用存儲(chǔ) Api，并從各個(gè)維度上進(jìn)行比較。

通過 FileSystem API, Web 應(yīng)用就可以創(chuàng)建、讀取、導(dǎo)航用戶本地文件系統(tǒng)中的沙盒部分以及向其中寫入數(shù)據(jù)。

API 被分為以下不同的主題：

讀取和處理文件：File/Blob、FileList、FileReader

創(chuàng)建和寫入：BlobBuilder、FileWriter

目錄和文件系統(tǒng)訪問：DirectoryReader、FileEntry/DirectoryEntry、LocalFileSystem

FileSystem API 是非標(biāo)準(zhǔn) API。在發(fā)布環(huán)境因慎重使用，因?yàn)椴⑹撬械臑g覽器都支持，實(shí)現(xiàn)方式可能存在很大的不兼容性，并且在將來可能也會(huì)發(fā)生變化。

網(wǎng)絡(luò)應(yīng)用可通過調(diào)用 window.requestFileSystem() 請求對沙盒文件系統(tǒng)的訪問權(quán)限：

// Note: The file system has been prefixed as of Google Chrome 12:
window.requestFileSystem = window.requestFileSystem || window.webkitRequestFileSystem;
window.requestFileSystem(type, size, successCallback, opt_errorCallback)

type：文件存儲(chǔ)是否應(yīng)該是持久的?？赡艿闹蛋?window.TEMPORARY 和 window.PERSISTENT。通過 TEMPORARY 存儲(chǔ)的數(shù)據(jù)可由瀏覽器自行決定刪除(例如在需要更多空間的情況下)，要清除PERSISTENT 存儲(chǔ)，必須獲得用戶或應(yīng)用的明確授權(quán)，并且需要用戶向你的應(yīng)用授予配額。

size: 應(yīng)用需要用于存儲(chǔ)的大小 (以字節(jié)為單位)。

successCallback：文件系統(tǒng)請求成功時(shí)調(diào)用的回調(diào)，其參數(shù)為 FileSystem 對象。

opt_errorCallback： 用于處理錯(cuò)誤或獲取文件系統(tǒng)的請求遭到拒絕時(shí)可選的回調(diào)，其參數(shù)為 FileError 對象。

如果你是首次調(diào)用 requestFileSystem()，系統(tǒng)會(huì)為你的應(yīng)用創(chuàng)建新的存儲(chǔ)。請注意，這是沙箱文件系統(tǒng)，也就是說，一個(gè)網(wǎng)絡(luò)應(yīng)用無法訪問另一個(gè)應(yīng)用的文件。

在訪問文件系統(tǒng)之后，可以對文件和目錄執(zhí)行大多數(shù)標(biāo)準(zhǔn)操作。

與其他存儲(chǔ)類型相比，文件系統(tǒng)是一個(gè)完全不同的存儲(chǔ)類型，因?yàn)樗闹荚跐M足數(shù)據(jù)庫，很不能很好地服務(wù)的客戶端存儲(chǔ)用例。通常，這些應(yīng)用程序處理大型二進(jìn)制blob或與瀏覽器上下文之外的應(yīng)用程序共享數(shù)據(jù)。

以下使用文件系統(tǒng) API 的幾個(gè)示例:

有上傳的應(yīng)用

當(dāng)你選擇一個(gè)文件或目錄進(jìn)行上傳時(shí)，你可以賦值文件到一個(gè)本地沙盒并一次上傳一個(gè)塊。

應(yīng)用可以在一次中斷后重新上傳，中斷可能包括瀏覽器被關(guān)閉或崩潰，連接中斷，或電腦被關(guān)閉。

視頻游戲或其他使用大量媒體資源的應(yīng)用

用下載一個(gè)或多個(gè)大壓縮包并在本地將他們解壓到一個(gè)文件目錄中。

應(yīng)用能在后臺(tái)預(yù)取資源，從而讓用戶能夠進(jìn)入下一項(xiàng)工作或游戲等級(jí)，而不需要等待下載。

音頻或照片編輯器使用線下訪問或本地緩存

應(yīng)用可以分段寫入文件（例如只覆蓋ID3/EXIF標(biāo)簽而不是整個(gè)文件）。

線下視頻瀏覽

應(yīng)用可以訪問只下載了部分的文件。

線下網(wǎng)絡(luò)郵件客戶端

客戶端下載附件并在本地存儲(chǔ)它們。

客戶端緩存附件用于稍后的上傳。

目前瀏覽器對文件系統(tǒng) API 的支持:

只讀的 localStorage 允許你訪問一個(gè) Document 的遠(yuǎn)端（origin）對象 Storage；其存儲(chǔ)的數(shù)據(jù)能在跨瀏覽器會(huì)話保留。 localStorage 類似 sessionStorage，其區(qū)別在于：存儲(chǔ)在 localStorage 的數(shù)據(jù)可以長期保留；而當(dāng)頁面會(huì)話結(jié)束——也就是說當(dāng)頁面被關(guān)閉時(shí)，存儲(chǔ)在 sessionStorage 的數(shù)據(jù)會(huì)被清除 。

應(yīng)注意無論數(shù)據(jù)存儲(chǔ)在 localStorage 還是 sessionStorage ，它們都特定于頁面的協(xié)議。

另外，localStorage 中的鍵值對總是以字符串的形式存儲(chǔ)。

當(dāng)前瀏覽器對API的支持:

sessionStorage 屬性允許你訪問一個(gè) session Storage 對象。它與 localStorage 相似，不同之處在于 localStorage 里面存儲(chǔ)的數(shù)據(jù)沒有過期時(shí)間設(shè)置，而存儲(chǔ)在 sessionStorage 里面的數(shù)據(jù)在頁面會(huì)話結(jié)束時(shí)會(huì)被清除。頁面會(huì)話在瀏覽器打開期間一直保持，并且重新加載或恢復(fù)頁面仍會(huì)保持原來的頁面會(huì)話。在新標(biāo)簽或窗口打開一個(gè)頁面時(shí)會(huì)在頂級(jí)瀏覽上下文中初始化一個(gè)新的會(huì)話，這點(diǎn)和 session cookies 的運(yùn)行方式不同。

應(yīng)該注意的是，無論是 localStorage 還是 sessionStorage 中保存的數(shù)據(jù)都僅限于該頁面的協(xié)議。

當(dāng)前瀏覽器對API的支持:

HTTP Cookie（也叫Web Cookie或?yàn)g覽器Cookie）是服務(wù)器發(fā)送到用戶瀏覽器并保存在本地的一小塊數(shù)據(jù)，它會(huì)在瀏覽器下次向同一服務(wù)器再發(fā)起請求時(shí)被攜帶并發(fā)送到服務(wù)器上。通常，它用于告知服務(wù)端兩個(gè)請求是否來自同一瀏覽器，如保持用戶的登錄狀態(tài)。Cookie 使基于無狀態(tài)的 HTTP 協(xié)議記錄穩(wěn)定的狀態(tài)信息成為了可能。

Cookie主要用于以下三個(gè)方面：

會(huì)話狀態(tài)管理（如用戶登錄狀態(tài)、購物車、游戲分?jǐn)?shù)或其它需要記錄的信息）

個(gè)性化設(shè)置（如用戶自定義設(shè)置、主題等）

*　瀏覽器行為跟蹤（如跟蹤分析用戶行為等）

Cookie曾一度用于客戶端數(shù)據(jù)的存儲(chǔ)，因當(dāng)時(shí)并沒有其它合適的存儲(chǔ)辦法而作為唯一的存儲(chǔ)手段，但現(xiàn)在隨著現(xiàn)代瀏覽器開始支持各種各樣的存儲(chǔ)方式，Cookie漸漸被淘汰。由于服務(wù)器指定Cookie后，瀏覽器的每次請求都會(huì)攜帶Cookie數(shù)據(jù)，會(huì)帶來額外的性能開銷（尤其是在移動(dòng)環(huán)境下）。

cookie 類型有兩種:

會(huì)話 Cookie ?—? 瀏覽器關(guān)閉之后它會(huì)被自動(dòng)刪除，也就是說它僅在會(huì)話期內(nèi)有效。會(huì)話期Cookie不需要指定過期時(shí)間（Expires）或者有效期（Max-Age）。需要注意的是，有些瀏覽器提供了會(huì)話恢復(fù)功能，這種情況下即使關(guān)閉了瀏覽器，會(huì)話期Cookie也會(huì)被保留下來，就好像瀏覽器從來沒有關(guān)閉一樣。

持久 Cookie —?和關(guān)閉瀏覽器便失效的會(huì)話期Cookie不同，持久性Cookie可以指定一個(gè)特定的過期時(shí)間（Expires）或有效期（Max-Age）。

當(dāng)機(jī)器處于不安全環(huán)境時(shí)，切記不能通過HTTP Cookie存儲(chǔ)、傳輸敏感信息，且所有瀏覽器都廣泛支持cookie。

Cache 接口為緩存的 Request/Response 對象對提供存儲(chǔ)機(jī)制，例如，作為 ServiceWorker 生命周期的一部分。請注意，Cache 接口像 workers 一樣，是暴露在 window 作用域下的。盡管它被定義在 service worker 的標(biāo)準(zhǔn)中, 但是它不必一定要配合 service worker 使用.

一個(gè)域可以有多個(gè)命名 Cache 對象。你需要在你的腳本 (例如，在 ServiceWorker 中)中處理緩存更新的方式。除非明確地更新緩存，否則緩存將不會(huì)被更新；除非刪除，否則緩存數(shù)據(jù)不會(huì)過期。使用 CacheStorage.open(cacheName) 打開一個(gè)Cache 對象，再使用 Cache 對象的方法去處理緩存.

你需要定期地清理緩存條目，因?yàn)槊總€(gè)瀏覽器都硬性限制了一個(gè)域下緩存數(shù)據(jù)的大小。緩存配額使用估算值，可以使用 StorageEstimate API 獲得。瀏覽器盡其所能去管理磁盤空間，但它有可能刪除一個(gè)域下的緩存數(shù)據(jù)。瀏覽器要么自動(dòng)刪除特定域的全部緩存，要么全部保留。確保按名稱安裝版本緩存，并僅從可以安全操作的腳本版本中使用緩存。查看 Deleting old caches 獲取更多信息.

CacheStorage 接口表示 Cache 對象的存儲(chǔ)。

它提供了一個(gè) ServiceWorker，其它類型worker或者 window 范圍內(nèi)可以訪問到的所有命名cache的主目錄（它并不是一定要和 service workers 一起使用，即使它是在 service workers 規(guī)范中定義的），并維護(hù)一份字符串名稱到相應(yīng) Cache 對象的映射。

使用 CacheStorage.open() 獲取 Cache 實(shí)例。

使用 CacheStorage.match() 檢查給定的 Request 是否是 CacheStorage 對象跟蹤的任何 Cache 對象中的鍵。

你可以通過 caches 屬性訪問 CacheStorage .

IndexedDB 是一種在用戶瀏覽器中持久存儲(chǔ)數(shù)據(jù)的方法。因?yàn)樗试S你創(chuàng)建具有豐富查詢功能的 Web 應(yīng)用程序，無論網(wǎng)絡(luò)可用性如何，這些應(yīng)用程序都可以在線和離線工作。IndexedDB 對于存儲(chǔ)大量數(shù)據(jù)的應(yīng)用程序(例如，借出庫中的 DVD 目錄)和不需要持久 internet 連接才能工作的應(yīng)用程序(例如，郵件客戶機(jī)、待辦事項(xiàng)列表和記事本)非常有用。

在本文中，會(huì)更詳細(xì)地討論存儲(chǔ)數(shù)據(jù)庫，因?yàn)槠溆嗟拇鎯?chǔ) Api 都是眾所周知的。另外，隨著 Web 應(yīng)用程序的復(fù)雜性越來越高，IndexedDB 也越來越受歡迎。

IndexedDB 通過“鍵”來存儲(chǔ)和檢索對象。對數(shù)據(jù)庫所做的所有更改都發(fā)生在事務(wù)中，像大多數(shù) Web 存儲(chǔ)解決方案一樣，IndexedDB 遵循同源策略。因此，雖然可以訪問域中存儲(chǔ)的數(shù)據(jù)，但是不能跨不同的域訪問數(shù)據(jù)。

IndexedDB 是一個(gè) 異步 API，可以在大多數(shù)上下文中使用，包括 WebWorkers。它過去也包括一個(gè)同步版本，供 Web 開發(fā)者使用，但是由于 Web 社區(qū)對它缺乏興趣，所以從規(guī)范中刪除了這個(gè)版本。

IndexedDB 曾經(jīng)有一個(gè)與之競爭的規(guī)范，稱為 WebSQL 數(shù)據(jù)庫，但是 W3C 棄用了它。雖然 IndexedDB 和WebSQL 都是存儲(chǔ)解決方案，但它們提供的功能不同。WebSQL 數(shù)據(jù)庫是一個(gè)關(guān)系數(shù)據(jù)庫訪問系統(tǒng)，而IndexedDB 是一個(gè)索引表系統(tǒng)。

不要一開始就使用 IndexedDB，這依賴于你對其他類型數(shù)據(jù)庫的假設(shè)。相反，應(yīng)該仔細(xì)閱讀文檔，以下是一些需要牢記的基本概念:

IndexedDB 數(shù)據(jù)庫使用 key-value 鍵值對儲(chǔ)存數(shù)據(jù) ?—? values 數(shù)據(jù)可以是結(jié)構(gòu)非常復(fù)雜的對象，key可以是對象自身的屬性。你可以對對象的某個(gè)屬性創(chuàng)建索引（index）以實(shí)現(xiàn)快速查詢和列舉排序。key可以是二進(jìn)制對象。

IndexedDB 是事務(wù)模式的數(shù)據(jù)庫 —? 任何操作都發(fā)生在事務(wù)(transaction)中。 IndexedDB API提供了索引(indexes)、表(tables)、指針(cursors)等等，但是所有這些必須是依賴于某種事務(wù)的。因此，你不能在事務(wù)外執(zhí)行命令或者打開指針。事務(wù)(transaction)有生存周期，在生存周期以后使用它會(huì)報(bào)錯(cuò)。并且，事務(wù)(transaction)是自動(dòng)提交的，不可以手動(dòng)提交。

The IndexedDB API 基本上是異步的 — IndexedDB 的 API 不通過 return 語句返回?cái)?shù)據(jù)，而是需要你提供一個(gè)回調(diào)函數(shù)來接受數(shù)據(jù)。執(zhí)行 API 時(shí)，你不以同步（synchronous）方式對數(shù)據(jù)庫進(jìn)行“存儲(chǔ)”和“讀取”操作，而是向數(shù)據(jù)庫發(fā)送一個(gè)操作“請求”。當(dāng)操作完成時(shí)，數(shù)據(jù)庫會(huì)以DOM事件的方式通知你，同時(shí)事件的類型會(huì)告訴你這個(gè)操作是否成功完成。這個(gè)過程聽起來會(huì)有些復(fù)雜，但是里面是有明智的原因的。這個(gè)和 XMLHttpRequest 請求是類似的。

IndexedDB數(shù)據(jù)庫“請求”無處不在 — 每一個(gè)“請求”都包含 onsuccess 和 onerror 事件屬性，同時(shí)你還對 “事件” 調(diào)用 addEventListener() 和 removeEventListener()?！罢埱蟆?還包括 readyState，result 和 errorCode 屬性，用來表示“請求”的狀態(tài)。result 屬性尤其神奇，他可以根據(jù)“請求”生成的方式變成不同的東西，例如：IDBCursor 實(shí)例、剛插入數(shù)據(jù)庫的數(shù)值對應(yīng)的鍵值（key）等。

IndexedDB是面向?qū)ο蟮?/strong> — indexedDB 不是用二維表來表示集合的關(guān)系型數(shù)據(jù)庫,這一點(diǎn)非常重要，將影響你設(shè)計(jì)和建立你的應(yīng)用程序。

這篇主要一些內(nèi)容原作者大部分是通過 MDN 整理的組合的，我也是根據(jù)中文的 MND 整理的組合。