— 從儲存機制聊到前後端分離架構下,登入狀態怎麼“記憶”
有一天,夥伴問我:「欸,那個 localStorage 跟 cookie 差在哪?sessionStorage 又是什麼?」
這個問題,不只是基礎,更是很多架構選擇的起點。
所以今天,我想從這三個常見的「瀏覽器端儲存技術」聊起,帶你一起思考一個非常實際的問題:在沒有後端 Session 的情況下,我們是怎麼記得一個人有登入的?
🔸 Cookie、localStorage、sessionStorage 是什麼?
這三個都是「在使用者瀏覽器端儲存資料」的方式,但他們的用途、特性與限制有些不同。
儲存方式 | 容量限制 | 是否自動送出給伺服器 | 存活時間 | 使用場景範例 |
---|---|---|---|---|
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」,那登入狀態怎麼辦?
前後端分離時,「登入狀態」怎麼記?
通常是這三個方式之一:
- JWT(JSON Web Token)
- 登入成功後,後端回傳一組加密的 Token
- 前端存下來(localStorage 或 cookie)
- 之後每次呼叫 API,把 Token 放在 Header 中(如 Authorization: Bearer xxx)
- 後端驗證 Token 來辨識使用者
- Cookie + Token
- 有些架構會把 Token 放在 HttpOnly 的 Cookie 中(增加安全性)
- 但這要搭配後端支援 Cookie-based 認證(例如 Laravel Sanctum)
- Refresh Token 策略
- Access Token 時效短(如 15 分鐘),Refresh Token 存放更長時間
- 可以避免 Token 過期就整個登出
最後聊一個思考點:
雖然我們經常會問:「登入狀態該放在哪裡?」
但其實真正該問的應該是:
「我要達到什麼樣的使用體驗與安全性?」
你是希望「跨頁不掉狀態」?還是「多裝置可登入」?
你是希望「Token 不被 JS 存取」?還是「前端能靈活控制登出邏輯」?
不同的需求,會有不同的技術選擇。
我們現在的問題已經不是「用 cookie 還是 localStorage」這麼單純,而是:
在 前後端分離架構下,如何設計一個兼顧安全與使用體驗的登入狀態記憶機制?
這個問題,值得每一個工程師細細琢磨。