PHP Session 過期機制深度解析與配置最佳實踐

許多開發者只知道改 `session.gc_maxlifetime`，卻不了解 PHP Session 採用**概率性垃圾回收 (GC)** 機制：過期文件不會立即刪除，而是等待下一次 GC 執行時才清理。本文徹底講透 Session 存儲、客戶端識別、過期判定、GC 觸發條件、特殊場景處理，給出生產環境配置建議。

Session 服務端存儲結構

• 默認路徑：`/tmp/sess_` (文件名 32 位十六進制)
• 文件內容格式：`變量名|類型:長度:值;` 例：`username|s:9:"jiangfeng";admin|s:1:"0";`
• 刪除文件 = Session 失效

客戶端識別：Session ID 傳遞方式

配置：`session.use_cookies=1`、`session.use_only_cookies=1` (建議，防 URL 泄露)、`session.use_trans_sid=0` (禁用 URL 傳遞)。

過期判定邏輯：文件 mtime + gc_maxlifetime

• 判斷依據：文件最後修改時間 (mtime) 距今是否超過 `session.gc_maxlifetime` (默認 1440 秒 = 24 分鐘)。
• 關鍵：`$_SESSION` 數據**未修改**不會更新文件 mtime。純讀取頁面不會延長壽命。
• 過期文件**不會自動消失**，需等待 GC 掃描刪除。

GC 觸發機制：概率性 (請求級)

; php.ini 默認
session.gc_probability = 1
session.gc_divisor     = 100
; 每次請求有 1/100 = 1% 概率觸發 GC
; 高併發建議：1/1000 ~ 1/5000
session.gc_divisor = 5000

• GC 觸發時機：`session_start()` 內部，在 `open`、`read` 後執行。
• GC 掃描 `session.save_path` 下所有 `sess_*` 文件，刪除 mtime 超過 `gc_maxlifetime` 的文件。
• 多應用共享 save_path 危險：若不同應用 `gc_maxlifetime` 不同，**最小值生效**，導致長壽命應用 Session 被誤刪。

特殊場景：活躍用戶但 Session 數據不變 → 被誤刪

用戶持續操作但只讀不寫 Session，文件 mtime 不更新，超過 `gc_maxlifetime` 後下次 GC 被刪除。

解決：定期更新 Session 觸發 mtime 刷新

<?php
// 每 60 秒寫入一次時間戳，保持文件 mtime 更新
if (!isset($_SESSION['_last_active']) || time() - $_SESSION['_last_active'] > 60) {
    $_SESSION['_last_active'] = time(); // 觸發 write，更新 mtime
}
?>

生產環境配置建議 (php.ini / .user.ini / ini_set)

集群/分布式環境：棄用文件，改用 Redis

; php.ini (需安裝 phpredis 擴展)
session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379?auth=yourpass&database=0"
; 內建支持鎖、原子操作、TTL 自動過期，無需手寫 GC

或使用成熟庫：predis/predis + 自定義 `SessionHandlerInterface` 實現。

總結：Session 過期「三步走」

1. 設置壽命：`session.gc_maxlifetime` 定義「不活躍最大秒數」。
2. 保持活躍：關鍵頁面寫入 `$_SESSION['_active'] = time()` 刷新 mtime。
3. 控制清理：調整 `gc_probability/divisor` 避免高峰期 GC 卡頓；共享存儲環境隔離 `save_path` 或遷移 Redis。