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

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

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

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

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

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

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

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

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

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

JavaScript 是如何工作的：Web Workers的構建塊+ 5個使用他們的場景!

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

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

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

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

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

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

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

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

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

在本章中，討論可選擇的存儲 Api 和服務，并提供一些在構建 Web應用程序，該使用哪種存儲引擎。

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

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

Key/Value: 鍵/值 數(shù)據(jù)存儲和相關的 NoSQL 數(shù)據(jù)庫提供了存儲和檢索由唯一鍵索引的非結構化數(shù)據(jù)的能力。鍵/值 數(shù)據(jù)存儲類似于哈希表，因為它們允許對索引的不透明數(shù)據(jù)進行長時間訪問。 鍵/值 數(shù)據(jù)存儲的代表例子是瀏覽器中的 Cache API 和服務器上的 Apache Cassandra。

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

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

web 應用程序的存儲方法可以根據(jù)數(shù)據(jù)持久化的時間段進行劃分：

會話持久化： 該類別中的數(shù)據(jù)僅在單個 Web 會話或瀏覽器選項卡保持激活狀態(tài)時才持久，具有會話持久性的存儲機制的一個示例是 Session Storage API。

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

此類中的數(shù)據(jù)跨會話和設備持久化。因此，它是最健壯的數(shù)據(jù)持久性形式。但是，它不能存儲在設備本身上，這意味需要在某種服務器端存儲。在這里不會詳細討論它，因為本文的重點是在設備本身上存儲數(shù)據(jù)。

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

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

瀏覽器支持 ?—? 標準化和完善的 API 更值得我們選擇，因為它們往往壽命更長，支持更廣泛， 這些API 還享有更豐富的文檔和開發(fā)人員社區(qū)。

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

同步/異步 — 有些存儲 Api 是同步的，因為存儲或檢索請求會阻塞當前活動的線程，直到請求完成。使用同步存儲 API 會阻塞主線程，并為 Web 應用程序的 UI 創(chuàng)建凍結體驗。如果可能，使用異步API。

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

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

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

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

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

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

FileSystem API 是非標準 API。在發(fā)布環(huán)境因慎重使用，因為并是所有的瀏覽器都支持，實現(xiàn)方式可能存在很大的不兼容性，并且在將來可能也會發(fā)生變化。

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

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

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

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

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

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

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

與其他存儲類型相比，文件系統(tǒng)是一個完全不同的存儲類型，因為它的旨在滿足數(shù)據(jù)庫，很不能很好地服務的客戶端存儲用例。通常，這些應用程序處理大型二進制blob或與瀏覽器上下文之外的應用程序共享數(shù)據(jù)。

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

有上傳的應用

當你選擇一個文件或目錄進行上傳時，你可以賦值文件到一個本地沙盒并一次上傳一個塊。

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

視頻游戲或其他使用大量媒體資源的應用

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

應用能在后臺預取資源，從而讓用戶能夠進入下一項工作或游戲等級，而不需要等待下載。

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

應用可以分段寫入文件（例如只覆蓋ID3/EXIF標簽而不是整個文件）。

線下視頻瀏覽

應用可以訪問只下載了部分的文件。

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

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

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

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

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

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

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

當前瀏覽器對API的支持:

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

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

當前瀏覽器對API的支持:

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

Cookie主要用于以下三個方面：

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

個性化設置（如用戶自定義設置、主題等）

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

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

cookie 類型有兩種:

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

持久 Cookie —?和關閉瀏覽器便失效的會話期Cookie不同，持久性Cookie可以指定一個特定的過期時間（Expires）或有效期（Max-Age）。

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

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

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

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

CacheStorage 接口表示 Cache 對象的存儲。

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

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

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

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

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

在本文中，會更詳細地討論存儲數(shù)據(jù)庫，因為其余的存儲 Api 都是眾所周知的。另外，隨著 Web 應用程序的復雜性越來越高，IndexedDB 也越來越受歡迎。

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

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

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

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

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

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

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

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

IndexedDB是面向對象的 — indexedDB 不是用二維表來表示集合的關系型數(shù)據(jù)庫,這一點非常重要，將影響你設計和建立你的應用程序。

indexedDB 不使用結構化查詢語言（SQL） — 它通過索引(index)所產(chǎn)生的指針(cursor)來完成查詢操作，從而使你可以迭代遍歷到結果集合。如果你不熟悉NoSQL系統(tǒng)，可以參考維基百科相關文章。

IndexedDB遵循同源（same-origin）策略 — “源”指腳本所在文檔URL的域名、應用層協(xié)議和端口。每一個“源”都有與其相關聯(lián)的數(shù)據(jù)庫。在同一個“源”內(nèi)的所有數(shù)據(jù)庫都有唯一、可區(qū)別的名稱。

以下情況不適合使用IndexedDB

全球多種語言混合存儲。國際化支持不好。需要自己處理。

和服務器端數(shù)據(jù)庫同步。你得自己寫同步代碼。

全文搜索。IndexedDB 接口沒有類似 SQL 語句中 LIKE 的功能。

注意，在以下情況下，數(shù)據(jù)庫可能被清除:

用戶請求清除數(shù)據(jù)。

瀏覽器處于隱私模式。最后退出瀏覽器的時候，數(shù)據(jù)會被清除。

硬盤等存儲設備的容量到限。

數(shù)據(jù)損壞。

進行與特性不兼容的操作。

確切的環(huán)境和瀏覽器特性會隨著時間改變，但瀏覽器廠商通常會遵循盡最大努力保留數(shù)據(jù)的理念。

確切的環(huán)境和瀏覽器特性會隨著時間改變，但瀏覽器廠商通常會遵循盡最大努力保留數(shù)據(jù)的理念。

如前所述，最好選擇盡可能多的瀏覽器廣泛支持的 Api，并提供異步調(diào)用模型，以最大限度地提高 UI 響應能力。這些標準自然會導致以下技術選擇:

對于離線存儲，請使用 Cache API。任何支持創(chuàng)建離線應用程序所需的 Service Worker technology 的瀏覽器都可以使用這個 API，Cache API 非常適合存儲與已知 URL 關聯(lián)的資源。

要存儲應用程序狀態(tài)和用戶生成的內(nèi)容，請使用IndexedDB。這使得用戶可以在更多的瀏覽器中離線工作，而不僅僅是那些支持緩存API的瀏覽器。

原文：

https://blog.sessionstack.com...

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

你的點贊是我持續(xù)分享好東西的動力，歡迎點贊！