[[272939]]

當 cookie 被首次引入時，它是瀏覽器保存數(shù)據(jù)的唯一方式。之后又有了很多新的選擇：Web Storage API、IndexedDB 和 Cache API。那么 cookie 死了嗎？我們來看看這些在瀏覽器中存儲數(shù)據(jù)的技術。

Cookies

Cookie 是由服務器發(fā)送或在客戶端上設置的信息單位，保存在用戶的本地瀏覽器上。它們會自動附加到每個請求上。由于 HTTP 是無狀態(tài)協(xié)議，因此 cookie 允許將信息存儲在客戶端上，以便將其他上下文數(shù)據(jù)傳給該服務器。

Cookie 有一些標志，對于提高數(shù)據(jù)的安全性非常有用。 HttpOnly 標志阻止用 JavaScript 訪問 cookie 的行為，只有附加在 HTTP 請求上時才能訪問它們。這非常適合防止通過 XSS（跨站點腳本）攻擊造成數(shù)據(jù)泄露。

此外，Secure 標志確保僅在通過 HTTPS 協(xié)議發(fā)送請求時才發(fā)送 cookie。 SameSite 標志，可以設置為 lax 或 strict（它們的差異看這里），可用于幫助防止 CSRF（跨站點請求偽造）請求。它告訴瀏覽器只有在請求是與請求者在同一域中的 URL 時才發(fā)送 cookie。

什么時候使用 cookies？

那么，在哪些情況下你希望獲得 Cookie？最常見的應用場景之一是授權 token 。由于 HttpOnly 標志為 XSS 攻擊添加了額外的保護層，SameSite 可以防止 CSRF，而 Secure 可以確保你的 cookie 被加密，這使你的身份驗證token 有額外的保護層。

由于 auth token 非常小，因此你無需擔心請求過大。此外由于它們會自動附加到每個請求，因此使用 cookie 可以在服務器上確定用戶是否經(jīng)過身份驗證。這對于服務器呈現(xiàn)的內(nèi)容非常有用，例如你希望將未經(jīng)過身份驗證的用戶重定向到登錄頁面。

Cookie 的另一個用途是存儲用戶的語言代碼。由于你可能希望在大多數(shù)請求中訪問用戶的語言，因此你可以利用它自動附加。

如何使用 cookies？

前面經(jīng)討論了要使用 cookie 的原因，現(xiàn)在來看看你可以如何使用 cookie。要從服務器上給客戶端設置 cookie，需要在 HTTP 響應中添加 Set-Cookie 標頭。 Cookie 應采用 key=value 的格式。如果你要在 Node.js 程序中設置 cookie，你的代碼可能像下面這樣：

response.setHeader('Set-Cookie', ['user_lang=en-us', 'user_theme=dark_mode']); 

這將會設置兩個 cookie：它將 user_lang 設置為 en-us，將 user_theme 設置為 dark_mode。

Cookie 也可以由客戶端操縱。要設置 cookie，可以用 key=value 的格式為 document.cookie 賦值。如果 key 已存在，則會被覆蓋掉。

document.cookie = 'user_lang=es-es'; 

如果已經(jīng)定義了 user_lang，它現(xiàn)在等于es-es。

你可以通過訪問 document.cookie 值來查看所有的 cookie。這將返回一串以分號做分隔的鍵值對。

document.cookie = 'user_lang=en-us';  
document.cookie = 'user_theme=light_mode';  
console.log(document.cookie); // 'user_lang=en-us; user_theme=light_mode;' 

要增加鍵值對的可訪問性，可以使用以下函數(shù)將此字符串解析為對象：

const parseCookies = x => x  
  .split(';')  
  .map(e => e.trim().split('='))  
  .reduce((obj, [key, value]) => ({...obj, [key]: value}), {}); 

If you need to set one of the flags onto your cookie, you can add them after a semicolon. For example, if you’d like to set the Secure and SameSite flags onto your cookie, you would do the following:

如果你需要將其中一個標志設置到 cookie 上，可以在分號后添加它們。例如你想在 Cookie 上設置 Secure 和 SameSite 標志，則可以執(zhí)行以下操作：

document.cookie = 'product_ids=123,321;secure;samesite=lax' 

由于 HTTPOnly 的作用是使 cookie 只能在服務器上訪問，因此它只能由服務器添加。

除了這些安全標志之外，你還可以設置 Max-Age（ cookie 應該保存的秒數(shù)）或 Expires（Cookie應該過期的日期）。如果這些都未設置，則 cookie 將跟隨瀏覽器會話的持續(xù)時間。如果用戶使用隱身模式，則會在用戶會話關閉時刪除 Cookie。

由于處理 cookie 的接口不是很友好，所以你可以使用諸如 js-cookie 之類的庫來方便對其的操作。

Web Storage API

Web Storage API 是一種在本地存儲數(shù)據(jù)的新選項。它在 HTML5 中中添加，Web Storage API 包括localStorage 和 sessionStorage。雖然 cookie 通常處理 server/client 通信，但 Web Storage API 最適用于保存客戶端數(shù)據(jù)。

我們已經(jīng)將 cookie 作為在本地存儲數(shù)據(jù)的選項，為什么還需要 Web 存儲？其中一個原因是：由于 cookie 會自動添加到每個 HTTP 請求中，因此請求大小會變得臃腫。所以你可以用 Web Storage API 存儲比 cookie 更大量的數(shù)據(jù)。

另一個優(yōu)點是更直觀的 API。如果使用 cookie，你需要手動解析 cookie 字符串來訪問各個鍵。 Web Storage 使這更加容易。如果要設置或獲取值，可以使用 setItem 或 getItem。

localStorage.setItem('selected_tab', 'FAQ');  
localSTorage.getItem('selected_tab'); // 'FAQ' 

鍵和值都必須是字符串。如果你想保存一個對象或數(shù)組，可以在保存時調用 JSON.stringify() 并在讀取時調用 JSON.parse() 來實現(xiàn)。

const product = {  
  id: '123',  
  name: 'Coffee Beans',  
};  
localStorage.setItem('cached_product', JSON.stringify(product));  
JSON.parse(localStorage.getItem('cached_product')); 

local storage 的另一個用例是在多個選項卡之間同步數(shù)據(jù)。通過為 'storage' 事件添加偵聽器，你可以在另一個選項卡或窗口中更新數(shù)據(jù)。

window.addEventListener('storage', () => {  
  console.log('local storage has been updated');  
}); 

僅當在另一個文檔中修改本地或會話存儲時才會觸發(fā)此事件。也就是說，你無法在當前瀏覽器選項卡中偵聽 storage 的更改。不幸的是，截至撰寫本文時，存儲事件監(jiān)聽器尚未在 Chrome 上得到支持。

那么localStorage 和 sessionStorage 之間有什么區(qū)別呢？與 cookie 不同，Web Storage API 沒有過期或最大期限功能。如果使用 localStorage，除非手動刪除，否則數(shù)據(jù)將無限期保留。你可以通過運行 localStorage.removeItem('key') 來刪除單個鍵的值，或者通過運行 localStorage.clear() 清除所有數(shù)據(jù)。

如果使用 sessionStorage，則數(shù)據(jù)將僅持續(xù)到當前會話結束。如果你沒有設置最大時間或過期，它將被視為與 cookie 保持的方式相似。在任何一種情況下，如果用戶使用隱身，本地存儲都不會在會話之間保留數(shù)據(jù)。

IndexedDB

如果 cookie 和 localStorage 都不符合你的要求，還有另一種選擇：IndexedDB，一個瀏覽器內(nèi)置的數(shù)據(jù)庫系統(tǒng)。

當 localStorage 同步執(zhí)行所有方法時，IndexedDB 會異步調用它們。這將會允許訪問數(shù)據(jù)而不會阻塞其余代碼。當你處理大量可能訪問代價高昂的代碼時，這非常有用。

IndexedDB 在其存儲的數(shù)據(jù)類型方面也具有更大的靈活性。雖然 cookies 和 localStorage 僅限于存儲字符串，但 IndexedDB 可以存儲可以通過“結構化克隆算法”復制的任何類型的數(shù)據(jù)。這包括 Object、 Date、 File、 Blob、 RegEx 以及更多類型。

性能和靈活性增加的缺點是 IndexedDB 的 API 更低級且更復雜。幸運的是有許多庫可以解決這個問題。

localForage 為 IndexedDB 提供了一個更簡單的類似 localStorage 的 API。 PouchDB 提供了一個可以離線的存儲 API，可以與在線 CouchDB 數(shù)據(jù)庫同步。 idb 是一個小型庫，具有更簡單的基于 promise 的 API。 Dexie 添加了更強大的查詢 API，同時保持了良好的性能。根據(jù)你的使用情況還有許多選擇。

Cache API

另一種用于持久數(shù)據(jù)的專用工具是 Cache API。雖然它最初是為 service workers 創(chuàng)建的，但它可用于緩存任何網(wǎng)絡請求。 Cache API 公開了 Window.caches，它提供了保存和檢索響應的方法，允許你保存可永遠以后訪問的 Requests 和 Responses 對。

例如，如果你想在從 API 請求響應之前檢查瀏覽器的緩存以獲取響應，則可以執(zhí)行以下操作：

const apiRequest = new Request('https://www.example.com/items');  
caches.open('exampleCache') // opens the cache  
  .then(cache => {  
    cache.match(apiRequest) // checks if the request is cached  
      .then(cachedResponse =>   
        cachedResponse || // return cachedReponse if available  
        fetch(apiRequest) // otherwise, make new request  
          .then(response => {  
            cache.put(apiRequest, response); // cache the response  
            return response;  
          })  
        })  
    .then(res => console.log(res))  
}) 

第一次運行代碼時，它將緩存響應。隨后每次都會緩存請求，并且不會發(fā)出網(wǎng)絡請求。

總結

在瀏覽器上存儲數(shù)據(jù)的每種方法都有其自己的用途。如果信息很小，很敏感，并且可能在服務器上使用，那么 cookie 就是最佳選擇。如果要保存更大且更不敏感的數(shù)據(jù)，Web Storage API 可能是更好的選擇。

如果你打算存儲大量結構化數(shù)據(jù)，IndexedDB 非常棒。 Cache API 用于存儲來自 HTTP 請求的響應。根據(jù)你的需要，有很多工具可供使用。