深入理解 Session 機制：為何多用戶不會互相覆蓋？

核心結論

每個客戶端（瀏覽器）擁有獨立的 Session，互不干擾，不會發生覆蓋。

Session 運作原理

1. Session ID 生成：用戶首次訪問時，伺服器生成唯一的 Session ID（如 PHP 的 PHPSESSID、Java 的 JSESSIONID）。
2. 客戶端儲存：Session ID 透過 Cookie（預設）或 URL 重寫傳回客戶端瀏覽器。
3. 伺服端儲存：真正的 Session 資料（如 $_SESSION['name']）儲存在伺服器記憶體、檔案、Redis 或資料庫中，以 Session ID 為鍵。
4. 後續請求：瀏覽器自動攜帶 Cookie 中的 Session ID，伺服器據此載入對應的 Session 資料。

為何不會覆蓋？

兩者 Session ID 不同，對應的儲存空間完全隔離。用戶 B 的登入操作只會建立/修改 xyz789 下的資料，絕不會觸及 abc123。

常見誤區澄清

• 誤區：「Session 是全域共用的。」
  事實：Session 資料結構 是全域的（伺服器有一個大陣列/表），但每個用戶只能存取自己 Session ID 對應的那一筆。
• 誤區：「關閉瀏覽器 Session 就消失了。」
  事實：預設 Session Cookie 是「會話級」（關閉瀏覽器失效），但伺服器端資料會保留到 GC（垃圾回收）清理為止（預設 24 分鐘）。

若確需跨用戶共享資料（全域 Session）

極少數場景（如線上人數統計、全站公告已讀狀態）需共享資料，可採用：

1. 資料庫：建立共享資料表，所有用戶讀寫同一張表。
2. Redis/Memcached：用共用 Key（如 global:announcement_read）存取，效能最佳。
3. 檔案/共享記憶體：小型專案可用，注意併發鎖。

切勿 嘗試用同一個 Session ID 服務多用戶，會導致嚴重的安全與邏輯錯誤。

最佳實踐建議

• 敏感資料（權限、用戶 ID）只存 Session，勿存 Cookie。
• 登入時 重新生成 Session ID（session_regenerate_id(true)），防 Session Fixation 攻擊。
• 登出時 銷毀 Session（session_destroy()）並清除 Cookie。
• 設定合理的 session.gc_maxlifetime 及 Cookie HttpOnly、Secure 標誌。

結語

Session 是「伺服器端狀態」配合「客戶端憑證」的機制。理解「Session ID 隔離」這一核心，即可釐清多用戶環境下的資料流向，避免誤以為會互相覆蓋。