Cookie 與 Session 深度解析：存儲位置、生命週期、安全性與選型指南

核心區別一覽

Cookie 詳細機制

組成字段

• Name / Value：鍵值對
• Expires / Max-Age：過期時間（舊版用 Expires，新版用 Max-Age，秒數）
• Domain：生效域名（如 .example.com 含子域名）
• Path：生效路徑（如 /app）
• Secure：僅 HTTPS 傳輸
• HttpOnly：禁止 JS 讀取（防 XSS），必開
• SameSite：Strict/Lax/None（防 CSRF），現代瀏覽器默認 Lax

生命週期

• 會話級 Cookie：無 Expires/Max-Age，瀏覽器進程結束銷毀，存內存
• 持久化 Cookie：設置過期時間，寫入硬盤，跨會話有效

Session 詳細機制

創建與識別流程

1. 客戶端首次請求，服務端檢查請求中是否攜帶 JSESSIONID（Cookie 或 URL 重寫）
2. 無 ID → 創建新 Session，生成唯一 SessionID（加密隨機串）
3. 響應頭 Set-Cookie: JSESSIONID=xxx; Path=/; HttpOnly 種植到瀏覽器
4. 後續請求自動攜帶 Cookie，服務端根據 ID 從存儲中獲取 Session 對象

存儲介質演進

1. 內存（單機、重啟丟失）
2. 文件/數據庫持久化（性能一般）
3. Redis 集群（高性能、共享、TTL 自動過期、序列化靈活）

URL 重寫（Cookie 被禁用時的降級）

將 SessionID 附加在 URL 參數或路徑中：url;jsessionid=xxx。Servlet API response.encodeURL(url) 自動判斷是否需要重寫。

安全性最佳實踐

1. 敏感信息絕不放 Cookie：用戶 ID、權限、Token 僅存 Session/Redis
2. Cookie 必開 HttpOnly + Secure（HTTPS 環境）
3. SameSite 設置 Lax 或 Strict，關鍵操作驗證 Token
4. SessionID 定期輪換：登錄成功、權限變更時 session.invalidate() 重建
5. 防 Session 固定攻擊：登錄前後 SessionID 必須不同

選型決策樹

需要跨瀏覽器會話持久化？ → 是 → Cookie（設置 Max-Age）
                                ↓ 否
數據敏感/大於 4KB/不想暴露給客戶端？ → 是 → Session (Redis)
                                ↓ 否
僅需客戶端輕量標識（如偏好設置、追蹤 ID）？ → Cookie
                                ↓ 否
服務端有狀態邏輯（購物車、權限、多步表單）？ → Session

經典組合拳

• 登錄態：Session 存用戶對象，Cookie 存 JSESSIONID（HttpOnly）
• 記住我：Cookie 存加密 Token（Max-Age 30 天），自動登錄時換取 Session
• 購物車：未登錄用 Cookie 存商品 ID/數量；登錄後合併到 Redis
• CSRF Token：Session 存 Token，表單隱藏域/請求頭攜帶驗證

總結

Cookie 是「客戶端身份證」，Session 是「服務端檔案櫃」。敏感、大數據、服務端邏輯用 Session（Redis）；非敏感、持久化、客戶端只讀用 Cookie。現代架構下，Session 必須外置到 Redis 實現無狀態水平擴展，Cookie 僅作為 SessionID 傳輸載體，並開啟全部安全屬性。