引言

隨著對前端的了解越來越深入，了解到了很多種瀏覽器的存儲方案，如 Cookie、LocalStorage等，哪這些存儲方案有何異同，分別的適用場景又是什么呢。

Cookie

Cookie的來源

Cookie 被創(chuàng)造出來的本意并不是本地儲存，而是為了辨別用戶身份。眾所周知，Http 協(xié)議是無狀態(tài)的，也就是說你每一次發(fā)送給服務器的請求對于服務器來說都是孤立的，服務器不知道這這些請求來自于誰。比如你向購物車里面添加了一些商品，但是當發(fā)送結(jié)賬請求的時候服務器懵了，我怎么知道你是誰，你買了什么呢。而使用 Cookie 之后，服務器就可以通過查看 Cookie 來判斷發(fā)送用戶，一定程度上 Cookies 可以說是請求的身份證。可以告訴服務器請求發(fā)送自誰。

Cookie是什么

百聞不如一見，直接來看看 Cookie 長啥樣

這是百度首頁使用的 Cookie ，如你所見，Cookie 是以 Name-Value 鍵值對儲存在瀏覽器中的，其中 Value 又是明顯經(jīng)過了加密的數(shù)據(jù)。

Cookie生成方式

Cookie 是所屬于域名的，還是百度首頁的 Cookie，通過 Domain 屬性可以得知前兩個 Cookie 是屬于 .baidu.com 的

每個域名只能設置與訪問到自己域名下的 Cookie，比如 baidu.com 無法訪問 Domain 為 sougou.com 的 Cookie。但是子域名可以讀取父域名設置的Cookie，比如截圖中 www.baidu.com 就讀取到了 Domain=’.baidu.com’ 的Cookie，通過手動設置 Domain 可以設置父域名的 Cookie，比如 www.baidu.com 可以設置Domain=’baidu.com’這樣 *.baidu.com 所有二級域名也能讀取到它設置的 Cookie

//www.baidu.comdocument.cookie=’age=20;domain=.baidu.com’// 此時 所有二級域名可以直接讀取到這個 Cookie

Cookie的生成方式分為 服務器端生成和瀏覽器端生成。

服務器端-通過設置 http response header中的set-cookie

我們可以通過響應頭里的 Set-Cookie 指定要存儲的 Cookie 值。當請求返回瀏覽器的時候瀏覽器就會按照 header 中的 set-cookie 值設置 Cookie。默認情況下，Domain 被設置為設置 Cookie 頁面的主機名，當然我們也可以手動設置 Domain 的值。

Set-Cookie: id=a3fWa;

瀏覽器端-js中可以通過document.cookie可以讀寫cookie，以鍵值對的形式展示

document.cookie='id=a3fWa'document.cookie=’age=20;domain=.baidu.com’Cookie的應用場景

既然 Cookie 的作用就是告訴服務器請求來自于誰，那么最主要的作用就是保持用戶登陸態(tài)（記住密碼），除此之外還可以記錄用戶瀏覽數(shù)據(jù)，進行廣告推送和前文提到的購物車等。

Cookie的缺點

缺點其實在前文中就很顯而易見了

不夠大

Cookie 會隨著每一次請求發(fā)送，這就注定了 Cookie 必定會有嚴格的大小限制，每一個 Cookie 的大小被限制在了 4kb，值得注意的是 4kb 指的是一個 Name-Value 的大小，而并不是說這個域名可以設置的 Cookie 總大小只有 4kb

性能缺陷

Cookie 是跟隨著域名的，會隨著每一個同域名請求發(fā)送，但是其實很大一部分請求，比如說圖片等靜態(tài)資源的請求是完全用不著 Cookie 的，雖然每個Cookie只有 4kb 但是積少成多也會帶來巨大的資源浪費。

我們可以把靜態(tài)資源放到 CDN 上去，這時候圖片域名就和主站域名不相同了，就不會附帶發(fā)送 Cookie

不夠安全

正如上文直接打開控制臺就可以看到 Cookie 一樣，Cookie 雖然通過編碼進行了加密，但在 Http 傳輸中是明文傳輸，腳本也可以很輕松的獲取到 Cookie，非常容易被破解。

在服務器端設置 Cookie 的時候附帶上 HttpOnly 標記，這樣在瀏覽器端就無法使用 document.cookie 訪問到這個 Cookie 了

Set-Cookie: id=a3fWa; HttpOnly

標記為 Secure 的 Cookie 只應通過 Https 協(xié)議加密過的請求發(fā)送，但是即便如此也不應該使用 Cookie 儲存敏感信息，因為 Cookie 有其固有的不安全性，這兩個標記也無法提供確切的安全保障。

解決方法

既然 Cookie 有這么多缺點，有沒有什么一勞永逸的解決方法呢，那就是「專業(yè)的人做專業(yè)的事」。

用戶登錄態(tài)和部分用戶信息的存儲的工作交給 Seesion ---即 Cookie 只用來儲存一個用戶唯一標識符，真正信息儲存在服務器端，使用 Cookie 作為 SeesionID 去服務器查找信息，這樣一來 Cookie 的容量限制，安全問題都引刃而解了，因為此時 Cookie 里面就是一串無意義的隨機碼。

本地儲存得工作交由html5 中新增本地存儲的解決方案「Web Storage」，它又分成兩類 ：localStorage和SessionStorage，接下來就介紹這兩兄弟。

LocalStorage特點 數(shù)據(jù)長時間保存，直到手動刪除為止 大小約為 5M 和 Cookie 一樣，一個網(wǎng)站只能訪問和操作自己網(wǎng)站域名下的數(shù)據(jù) 僅在客戶端使用，和服務端無通信 接口封裝較好 使用鍵值對保存信息 同源窗口都可以訪問使用示例

LocalStorage 使用非常方便：

// 設置數(shù)據(jù)localStorage.setItem('key','value');//讀取數(shù)據(jù)let valueLocal = localStorage.getItem('key');使用場景

通過上面那些特性就可以看出 LocalStorage 非常適合用來做本地緩存，可以提高首屏加載速度。一些圖片等不會經(jīng)常改變的大資源也可以緩存下來，減少網(wǎng)絡請求。

SeesionStorage特點 保存時間為本次會話，也就是說窗口關(guān)閉就沒了 僅本窗口可以訪問，同源的其他窗口都不行大 小約為 5M使用場景

sessionStorage 更適合用來存儲生命周期和它同步的會話級別的信息。這些信息只適用于當前會話，比如可以用來做表單數(shù)據(jù)的持久化，防止刷新后表單數(shù)據(jù)丟失

Cookie、LocalStorage 和SessionStorage 之間的區(qū)別作用域的不同

這三者都遵循協(xié)議，即同協(xié)議，同域名，同端口下才能訪問和修改同一份數(shù)據(jù)，唯一不同的就是 SeesionStorage 還要求在同一窗口。

生命周期的不同 Cookie可以手動設置過期時間，默認就是本次會話時長，隨著窗口關(guān)閉而刪除，當設置了過期時間時候，就會被儲存到硬盤中直到過期時間才被刪除 LocalStorage是持久化的本地儲存，除非你手動刪除，否則會一直存在 SessionStorage是會話級別的存儲，也是隨著窗口關(guān)閉而刪除。總結(jié)

這就是幾種瀏覽器存儲方案，當然還有我們應該根據(jù)不同方案各自的特點決定什么時候使用什么方案，適合的才是最好的。總結(jié)一下本文的幾個重點

Cookie 的本職工作并非本地存儲，而是“維持狀態(tài)” Web Storage 是html5 專門為瀏覽器存儲而提供的數(shù)據(jù)存儲機制，不與服務端發(fā)生通信

以上就是詳解JS瀏覽器儲存的詳細內(nèi)容，更多關(guān)于JS瀏覽器儲存的資料請關(guān)注好吧啦網(wǎng)其它相關(guān)文章！