您应该自己实现会话超时。其他人提到的两个选项_session.gc_maxlifetime_和_session.cookie_lifetime_都不可靠。我将解释其原因。

第一：

session.gc_maxlifetime
session.gc_maxlifetime 指定秒数，此后将数据视为“垃圾”并清除。垃圾收集在会话开始期间发生。

但是，垃圾回收器仅以_session.gc_probability_除以_session.gc_divisor_的概率启动。使用这些选项的默认值（分别为1和100），机会只有1％。

好吧，您可以简单地调整这些值，以便更频繁地启动垃圾收集器。但是，当启动垃圾收集器时，它将检查每个已注册会话的有效性。这是高成本的。

此外，当使用PHP的默认_session.save_handler文件时，会话数据存储在_session.save_path_指定的路径中的文件中。使用该会话处理程序，会话数据的期限是根据文件的最后修改日期而不是最后访问日期计算的：

注意： 如果使用默认的基于文件的会话处理程序，则文件系统必须跟踪访问时间（atime）。Windows
FAT并非如此，如果您卡在FAT文件系统或任何其他无法进行时间跟踪的文件系统上，则您将不得不想出另一种方式来处理会话的垃圾回收。从PHP 4.2.3开始，它使用mtime（修改日期）代替atime。因此，对于没有时间跟踪功能的文件系统，您不会有任何问题。

因此，还可能会发生以下情况：删除会话数据文件，而由于会话数据最近未更新，因此会话本身仍被视为有效会话。

第二：

session.cookie_lifetime
session.cookie_lifetime 指定发送到浏览器的cookie的生存时间（以秒为单位）。[…]

恩，那就对了。这只会影响cookie的生存期，会话本身可能仍然有效。但是使会话无效是服务器的任务，而不是客户端。因此，这无济于事。实际上，将_session.cookie_lifetime_设置为0将会使会话的cookie成为真正的会话cookie，该cookie仅在关闭浏览器之前才有效。

结论/最佳解决方案：

最好的解决方案是实现自己的会话超时。使用一个简单的时间戳记来表示上一个活动（即请求）的时间，并随每个请求进行更新：

if (isset($_SESSION['LAST_ACTIVITY']) && (time() - $_SESSION['LAST_ACTIVITY'] > 1800)) {
    // last request was more than 30 minutes ago
    session_unset();     // unset $_SESSION variable for the run-time 
    session_destroy();   // destroy session data in storage
}
$_SESSION['LAST_ACTIVITY'] = time(); // update last activity time stamp

在每个请求中更新会话数据也会更改会话文件的修改日期，以便垃圾收集器不会过早删除该会话。

您还可以使用其他时间戳记来定期重新生成会话ID，以避免攻击会话，例如会话固定：

if (!isset($_SESSION['CREATED'])) {
    $_SESSION['CREATED'] = time();
} else if (time() - $_SESSION['CREATED'] > 1800) {
    // session started more than 30 minutes ago
    session_regenerate_id(true);    // change session ID for the current session and invalidate old session ID
    $_SESSION['CREATED'] = time();  // update creation time
}

笔记：

• session.gc_maxlifetime 应至少等于此自定义过期处理程序的生存期（在此示例中为1800）；
• 如果您要在 活动 30分钟后而不是 从启动 后30分钟后使会话setcookie过期，则还需要使用到期时间time()+60*30来保持会话cookie的活动。