PHP Session 嚴格超時控制：雙重保障機制實現

單純依賴 session.gc_maxlifetime 不可靠：GC 是概率觸發（gc_probability/gc_divisor），且無法精確控制單用戶閒置超時。需結合「伺服器端時間戳驗證」實現嚴格管控。

方案一：配置層面（基礎防線）

ini_set('session.gc_maxlifetime', 3600);   // GC 最大生存 1 小時
ini_set('session.cookie_lifetime', 3600);  // Cookie 存活 1 小時（0 為瀏覽器關閉即失效）

缺點：GC 不準時、無法針對單用戶、跨伺服器共享 Session 時需統一存儲。

方案二：應用層時間戳驗證（核心邏輯）

<?php
session_start();

const IDLE_TIMEOUT = 3600; // 1 小時無操作視為超時

// 1. 檢查是否已登錄且未超時
if (isset($_SESSION['user_id'])) {
    $now = time();
    if (isset($_SESSION['last_activity']) && ($now - $_SESSION['last_activity'] > IDLE_TIMEOUT)) {
        // 超時：銷毀會話並跳轉登錄
        session_unset();
        session_destroy();
        header('Location: login.php?timeout=1');
        exit;
    }
    // 未超時：刷新最後活動時間
    $_SESSION['last_activity'] = $now;
}

// 2. 登錄成功時初始化
// $_SESSION['user_id'] = $userId;
// $_SESSION['last_activity'] = time();

進階：結合 Redis 實現分散式 Session 超時

// 使用 Redis 存儲 Session，Key 設置 TTL
// Key: session:{session_id}  Value: JSON(session_data)  Expire: 3600

// 每次請求：
$redis->expire("session:{$sessionId}", 3600); // 滑動過期，續期

// 優點：天然支援集群、TTL 精確到秒、無 GC 隨機性、可直接掃描過期 Key 做統計。

關鍵配置對照表

最佳實踐清單

• ✅ 入口文件統一 session_start() 並執行超時檢查中間件。
• ✅ 關鍵操作（支付、改密）二次驗證 last_activity。
• ✅ 使用 Redis/Memcached 替代文件存儲，配合 TTL 實現精準滑動過期。
• ✅ 前端定時心跳（如 30 分鐘一次）保持長會話業務場景。
• ✅ 登出時同時清理伺服器端 Session 與客戶端 Cookie。