— 從儲存機制聊到前後端分離架構下，登入狀態怎麼“記憶”
有一天，夥伴問我：「欸，那個 localStorage 跟 cookie 差在哪？sessionStorage 又是什麼？」
這個問題，不只是基礎，更是很多架構選擇的起點。所以今天，我想從這三個常見的「瀏覽器端儲存技術」聊起，帶你一起思考一個非常實際的問題：在沒有後端 Session 的情況下，我們是怎麼記得一個人有登入的？
🔸 Cookie、localStorage、sessionStorage 是什麼？
這三個都是「在使用者瀏覽器端儲存資料」的方式，但他們的用途、特性與限制有些不同。
它們的「使用時機」是什麼？
這邊我用幾個簡單情境來說明：
- 登入之後要記住狀態？→ 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」這麼單純，而是：
在 前後端分離架構下，如何設計一個兼顧安全與使用體驗的登入狀態記憶機制？
這個問題，值得每一個工程師細細琢磨。
