Image

你知道 Cookie、LocalStorage、SessionStorage 的使用時機嗎?

— 從儲存機制聊到前後端分離架構下,登入狀態怎麼“記憶”

有一天,夥伴問我:「欸,那個 localStorage 跟 cookie 差在哪?sessionStorage 又是什麼?」

這個問題,不只是基礎,更是很多架構選擇的起點。

所以今天,我想從這三個常見的「瀏覽器端儲存技術」聊起,帶你一起思考一個非常實際的問題:在沒有後端 Session 的情況下,我們是怎麼記得一個人有登入的?


這三個都是「在使用者瀏覽器端儲存資料」的方式,但他們的用途、特性與限制有些不同。

儲存方式容量限制是否自動送出給伺服器存活時間使用場景範例
Cookie約 4KB✅(每次 HTTP request)可設定過期時間記住登入狀態、追蹤用戶
localStorage約 5~10MB❌(不會自動送出)永久(除非主動清除)偏好設定、暫存資料
sessionStorage約 5~10MB分頁關閉即清除單一頁面流程、表單暫存

它們的「使用時機」是什麼?

這邊我用幾個簡單情境來說明:

  • 登入之後要記住狀態?→ Cookie 比較適合,尤其是伺服器要參與身份驗證的情況。
  • 希望跨頁、跨次開啟瀏覽器還能記得偏好設定(例如深色模式)? → localStorage 是不錯的選擇。
  • 表單填到一半,怕刷新頁面資料消失? → sessionStorage 派上用場。

這三種方式,其實是依照「儲存時間長短」、「資料是否送給後端」、「資料大小」來做選擇。


那麼,「登入狀態」到底該放哪裡?

傳統的 Web 架構(如 Laravel Blade 或 PHP)會在伺服器端維護 Session,並搭配 Cookie(通常是 PHPSESSID)來記住誰是誰。

但現在愈來愈多網站是「前後端分離」的架構(如 Vue + Laravel API、React + Node.js),這時候情況就不一樣了:

  • 前端不再透過 Cookie 自動送出 Session ID
  • 後端變成純 API,stateless,無狀態
  • 沒有「Session」,那登入狀態怎麼辦?

前後端分離時,「登入狀態」怎麼記?

通常是這三個方式之一:

  1. JWT(JSON Web Token)
    • 登入成功後,後端回傳一組加密的 Token
    • 前端存下來(localStorage 或 cookie)
    • 之後每次呼叫 API,把 Token 放在 Header 中(如 Authorization: Bearer xxx)
    • 後端驗證 Token 來辨識使用者
  2. Cookie + Token
    • 有些架構會把 Token 放在 HttpOnly 的 Cookie 中(增加安全性)
    • 但這要搭配後端支援 Cookie-based 認證(例如 Laravel Sanctum)
  3. Refresh Token 策略
    • Access Token 時效短(如 15 分鐘),Refresh Token 存放更長時間
    • 可以避免 Token 過期就整個登出

最後聊一個思考點:

雖然我們經常會問:「登入狀態該放在哪裡?」

但其實真正該問的應該是:

「我要達到什麼樣的使用體驗與安全性?」

你是希望「跨頁不掉狀態」?還是「多裝置可登入」?

你是希望「Token 不被 JS 存取」?還是「前端能靈活控制登出邏輯」?

不同的需求,會有不同的技術選擇。

我們現在的問題已經不是「用 cookie 還是 localStorage」這麼單純,而是:

前後端分離架構下,如何設計一個兼顧安全與使用體驗的登入狀態記憶機制?

這個問題,值得每一個工程師細細琢磨。