為什麼需要cookie跟session這東西？

根本原因只有一個：HTTP 協定是 Stateless (無狀態) 的。

這代表每個 HTTP Request 對 Server 來說都是獨立事件，它不會記得你上個 Request 做了什麼。如果沒有額外機制，你每點一個連結或刷新頁面，Server 都會當你是第一次來，導致剛登入就馬上被登出。

為了解決這個問題，讓 Server 能在跨 Request 的場景下識別使用者狀態（如登入、購物車），就需要 Session 和 Cookie 協同工作。

簡單類比一下：
你 (Client)：使用者瀏覽器
店家 (Server)：網站後端
Cookie：你手上的會員卡 (上面只有一組編號)
Session：店家櫃檯裡，你的那份會員檔案 (存著你的詳細資料)

技術拆解

Cookie

本質：存放在 Client 端 (瀏覽器) 的一小段 Key-Value 文字檔。由 Server 透過 Set-Cookie Header 發給瀏覽器。

作用：當作識別證。瀏覽器在後續對同一個 Server 發送的所有 Request 中，都會自動在 Cookie Header 裡帶上它。

儲存點：Client 端的瀏覽器。

內容：通常只放不敏感的識別用資料，最核心的就是 Session ID。其他像是語系偏好、佈景主題也能放。

安全性：低。因為資料直接暴露在 Client 端，可以被使用者查看、修改，也可能被攔截。

生命週期：可由 Server 設定效期 (expires)。可以是瀏覽器關閉就失效 (Session Cookie)，也可以是持續數天的永久 Cookie。

Session

本質：在 Server 端為特定 Client 建立的一個專屬資料儲存區，通常是存在記憶體、檔案或資料庫裡。

作用：記錄特定使用者的「狀態」，例如登入資訊、權限等級、購物車內容等。

儲存點：Server 端。

內容：可以存放任何類型、大量且敏感的資料。

安全性：高。因為所有資料都封裝在 Server 內部，Client 端無法直接存取，只能透過 Server 發的 Session ID 間接對應。

生命週期：Server 端管理。通常在使用者閒置超時 (Timeout) 或主動登出時銷毀。

完整工作流程 (Workflow)

整個流程的核心就是用 Cookie 來傳遞 Session ID。

Step 1：Server 建立 Session
使用者首次訪問或登入成功時，Server 會在後端為他建立一個 Session，並產生一個全域唯一的 Session ID 來當作這個 Session 的 Key，然後將使用者的狀態資料存進去。

Step 2：Server 回傳 Session ID (透過 Cookie)
Server 在 HTTP Response Header 中，透過 Set-Cookie 指令，將剛產生的 session_id 送回給瀏覽器。通常還會加上 HttpOnly 標記來防止前端腳本存取，增加安全性。

Step 3：瀏覽器後續 Request 自動帶上 Cookie
瀏覽器收到這個 Cookie 後會存起來。之後所有對同網域的 Request，都會自動在 Header 中夾帶這個 Cookie。

Step 4：Server 驗證 Session ID 並還原狀態
Server 收到 Request，從 Cookie Header 讀取到 session_id。接著拿這個 ID 去後端儲存區查找對應的 Session 資料。只要能找到，Server 就能還原使用者之前的狀態，並回傳對應的資料。

下一步

理論講完了，明天我們就來打開開發者工具，看看我們這幾天學到的內容。