瀏覽器的緩存機制提供了可以將用戶數據存儲在客戶端上的方式，可以利用cookie,session等跟服務端進行數據交互。
一、cookie和session
cookie和session都是用來跟蹤瀏覽器用戶身份的會話方式。
區別：
1、保持狀態：cookie保存在瀏覽器端，session保存在服務器端
2、使用方式：
（1）cookie機制：如果不在瀏覽器中設置過期時間，cookie被保存在內存中，生命周期隨瀏覽器的關閉而結束，這種cookie簡稱會話cookie。如果在瀏覽器中設置了cookie的過期時間，cookie被保存在硬盤中，關閉瀏覽器后，cookie數據仍然存在，直到過期時間結束才消失。
Cookie是服務器發給客戶端的特殊信息，cookie是以文本的方式保存在客戶端，每次請求時都帶上它
（2）session機制：當服務器收到請求需要創建session對象時，首先會檢查客戶端請求中是否包含sessionid。如果有sessionid，服務器將根據該id返回對應session對象。如果客戶端請求中沒有sessionid，服務器會創建新的session對象，並把sessionid在本次響應中返回給客戶端。通常使用cookie方式存儲sessionid到客戶端，在交互中瀏覽器按照規則將sessionid發送給服務器。如果用戶禁用cookie，則要使用URL重寫，可以通過response.encodeURL(url) 進行實現；API對encodeURL的結束為，當瀏覽器支持Cookie時，url不做任何處理；當瀏覽器不支持Cookie的時候，將會重寫URL將SessionID拼接到訪問地址后。
3、存儲內容：cookie只能保存字符串類型，以文本的方式；session通過類似與Hashtable的數據結構來保存，能支持任何類型的對象(session中可含有多個對象)
4、存儲的大小：cookie：單個cookie保存的數據不能超過4kb；session大小沒有限制。
5、安全性：cookie：針對cookie所存在的攻擊：Cookie欺騙，Cookie截獲；session的安全性大於cookie。
原因如下：（1）sessionID存儲在cookie中，若要攻破session首先要攻破cookie；
（2）sessionID是要有人登錄，或者啟動session_start才會有，所以攻破cookie也不一定能得到sessionID；
（3）第二次啟動session_start后，前一次的sessionID就是失效了，session過期后，sessionID也隨之失效。
（4）sessionID是加密的
（5）綜上所述，攻擊者必須在短時間內攻破加密的sessionID，這很難。
6、應用場景：
cookie：（1）判斷用戶是否登陸過網站，以便下次登錄時能夠實現自動登錄（或者記住密碼）。如果我們刪除cookie，則每次登錄必須從新填寫登錄的相關信息。
（2）保存上次登錄的時間等信息。
（3）保存上次查看的頁面
（4）瀏覽計數
session：Session用於保存每個用戶的專用信息，變量的值保存在服務器端，通過SessionID來區分不同的客戶。
（1）網上商城中的購物車
（2）保存用戶登錄信息
（3）將某些數據放入session中，供同一用戶的不同頁面使用
（4）防止用戶非法登錄
7、缺點：cookie：（1）大小受限
（2）用戶可以操作（禁用）cookie，使功能受限
（3）安全性較低
（4）有些狀態不可能保存在客戶端。
（5）每次訪問都要傳送cookie給服務器，浪費帶寬。
（6）cookie數據有路徑（path）的概念，可以限制cookie只屬於某個路徑下。
session：（1）Session保存的東西越多，就越占用服務器內存，對於用戶在線人數較多的網站，服務器的內存壓力會比較大。
（2）依賴於cookie（sessionID保存在cookie），如果禁用cookie，則要使用URL重寫，不安全
（3）創建Session變量有很大的隨意性，可隨時調用，不需要開發者做精確地處理，所以，過度使用session變量將會導致代碼不可讀而且不好維護。
二、WebStorage
WebStorage的目的是克服由cookie所帶來的一些限制，當數據需要被嚴格控制在客戶端時，不需要持續的將數據發回服務器。
WebStorage兩個主要目標：（1）提供一種在cookie之外存儲會話數據的路徑。（2）提供一種存儲大量可以跨會話存在的數據的機制。
HTML5的WebStorage提供了兩種API：localStorage（本地存儲）和sessionStorage（會話存儲）。
1、生命周期：localStorage:localStorage的生命周期是永久的，關閉頁面或瀏覽器之后localStorage中的數據也不會消失。localStorage除非主動刪除數據，否則數據永遠不會消失。
sessionStorage的生命周期是在僅在當前會話下有效。sessionStorage引入了一個“瀏覽器窗口”的概念，sessionStorage是在同源的窗口中始終存在的數據。只要這個瀏覽器窗口沒有關閉，即使刷新頁面或者進入同源另一個頁面，數據依然存在。但是sessionStorage在關閉了瀏覽器窗口后就會被銷毀。同時獨立的打開同一個窗口同一個頁面，sessionStorage也是不一樣的。
2、存儲大小：localStorage和sessionStorage的存儲數據大小一般都是：5MB
3、存儲位置：localStorage和sessionStorage都保存在客戶端，不與服務器進行交互通信。
4、存儲內容類型：localStorage和sessionStorage只能存儲字符串類型，對於復雜的對象可以使用ECMAScript提供的JSON對象的stringify和parse來處理
5、獲取方式：localStorage：window.localStorage;；sessionStorage：window.sessionStorage;。
6、應用場景：localStoragese：常用於長期登錄（+判斷用戶是否已登錄），適合長期保存在本地的數據。sessionStorage：敏感賬號一次性登錄；
WebStorage的優點：
（1）存儲空間更大：cookie為4KB，而WebStorage是5MB；
（2）節省網絡流量：WebStorage不會傳送到服務器，存儲在本地的數據可以直接獲取，也不會像cookie一樣美詞請求都會傳送到服務器，所以減少了客戶端和服務器端的交互，節省了網絡流量；
（3）對於那種只需要在用戶瀏覽一組頁面期間保存而關閉瀏覽器后就可以丟棄的數據，sessionStorage會非常方便；
（4）快速顯示：有的數據存儲在WebStorage上，再加上瀏覽器本身的緩存。獲取數據時可以從本地獲取會比從服務器端獲取快得多，所以速度更快；
（5）安全性：WebStorage不會隨着HTTP header發送到服務器端，所以安全性相對於cookie來說比較高一些，不會擔心截獲，但是仍然存在偽造問題；
（6）WebStorage提供了一些方法，數據操作比cookie方便；
- 保存數據：localStorage.setItem(key,value);
- 讀取數據：localStorage.getItem(key);
- 刪除單個數據：localStorage.removeItem(key);
- 刪除所有數據：localStorage.clear();
- 得到某個索引的key：localStorage.key(index);
登陸信息用cookie好還是localStorage好？
你的需求可以拆成兩個部分：認證 和 鑒權
認證識別這個用戶的身份
鑒權確定這個用戶訪問首頁之后是否需要跳轉到綁定支付頁面
cookie 天生就是最適合做認證，除了你提出的能否設置過期時間上的區別， cookie 和 localStorage 最大的區別是：每次 request 都會自動在 header 中帶上所有的 cookie。所以如果你為了鑒權，設置很多 cookie ，還會引發一個問題就是，每次 request 的包都會很大。
我的解決方案很簡單：鑒權就應該交給后端去做。無論你多么細心的在 client 中維護用戶權限標識，都需要確保一點：用戶的真實權限是否保持同步？所以你還是需要向后端查詢用戶權限設置，干嘛不簡單些：
用戶認證之后，后端鑒權，提示是否跳轉，或者干脆在 header 頭中設置跳轉鏈接。
首先，是登錄信息：
登錄信息存在 cookie 中是一直以來的做法，而且實現的很好，不用考慮各種問題。
而 localStorage 是在這個 API 誕生之后，一些 JS 黨帶起來的另一種實現方式。
使用 localStorage，你需要在每次請求的時候，都手動帶上這個信息，這大大增加了開發過程中帶來的困難，非常麻煩，而且還要手動維護過期時間。
而使用 cookie 的話，只需要在后端的 Auth 模塊放個設置 header 的代碼即可，其他完全不用考慮。為什么：
- 用戶未登錄的情況下，Auth 判斷沒有權限，設置個跳轉到登錄頁（或者是其他邏輯，比如以訪客身份瀏覽之類的）
- 用戶登錄時：將賬號和密碼 POST 到 Auth 模塊后，Auth 設置一個 header，設置 Cookie 及過期時間
- 用戶登錄后，在 Cookie 的有效期內（設置了過期時間就是過期時間內，沒設置就是瀏覽器關閉前），任何請求都會自動帶上 cookie，完全不用人工干預（fetch 請求除外，需要額外指定配置）
- 在用戶自動帶上 cookie 請求后，需要授權的請求一定會經過 Auth 模塊，判斷 cookie 是否有效（防止惡意無效的 cookie），若 cookie 無效，則
設置 header 刪除 cookie（可選步驟），並將用戶重定向到登錄頁。若 cookie 有效，則設置 header，為 cookie 續期（cookie 內容都可以完全不變）。
Auth 模塊：
if (POST 方法請求登錄) { if (賬號密碼不正確) { return 重定向到登錄頁面，並提示錯誤 } 設置 cookie，並指定過期時間為當前時間 +n 天 return Auth 模塊邏輯結束，進入其他模塊邏輯 } if (沒有 cookie) { return 重定向到登錄頁面 } if (cookie 無效) { // 可選步驟：設置 cookie 過期時間為 -1 （刪除 cookie） return 重定向到登錄頁面 } // 帶了有效的 cookie 設置 cookie 過期時間為當前時間 +n 天（為 cookie 續期） return Auth 模塊邏輯結束，進入其他模塊邏輯注意：只有請求 Auth 模塊才會給 cookie 續期，其他模塊不續。所以權限認證的模塊都統一到一起了