session.gc_maxlifetime 设置的是会话数据在服务器端自最后写入起最多保留的秒数，而非倒计时存活时长；其生效依赖 gc 概率机制，且需与存储层（如 redis ttl）对齐，不能单独用于实现精准闲置登出。
session.gc_maxlifetime 设置的是什么
它控制的是 PHP 会话数据在服务器端（如文件系统或 Redis）被垃圾回收器判定为“过期”并清理的最长时间，单位是秒。session.gc_maxlifetime 不是 session_start() 后倒计时的“存活时长”，而是“自最后写入时间起，最多保留多久”。
常见误解：设成 300 就代表用户 5 分钟不操作就自动登出——实际是否触发清理，还取决于 session.gc_probability 和 session.gc_divisor 的配合，且默认文件存储下 GC 并非每次请求都运行。
- 必须在
session_start()前设置，否则无效 - 若用 Redis 存储 session，该值仍需与 Redis 的 key 过期时间对齐，否则 GC 不起作用
- CLI 环境下 GC 几乎不触发，不能依赖它做超时清理
如何真正让会话在闲置后自动失效
服务端 GC 是被动机制，要实现“用户闲置 N 秒后登出”，必须结合客户端活跃状态判断。推荐在每次请求时更新会话内的时间戳，并在 session_start() 后立即校验：
session_start();
if (isset($_SESSION['last_activity']) && (time() - $_SESSION['last_activity'] > 300)) {
session_unset();
session_destroy();
setcookie(session_name(), '', time() - 3600, '/');
header('Location: /login.php');
exit;
}
$_SESSION['last_activity'] = time();- 这个逻辑必须放在所有 session 操作之前，否则可能读到过期数据
-
setcookie(..., time() - 3600)是清除客户端 session cookie 的关键一步，否则浏览器下次仍会带上旧 ID - 不要只依赖
$_SESSION['last_activity']，还要检查$_SESSION['user_id']是否合法，防止空 session 被复用
PHP-FPM + Apache/Nginx 下的常见失效陷阱
Web 服务器和 PHP 运行模式会影响 session 生命周期的实际表现：
立即学习“PHP免费学习笔记（深入）”；
- Apache 的
mod_php下，session.gc_maxlifetime由 php.ini 控制；但 PHP-FPM 模式下，每个 pool 可能加载独立配置，需确认phpinfo()中显示的值来源 - Nginx 默认不传递
PHP_VALUE，若通过 fastcgi_param 设置php_value[session.gc_maxlifetime]，需确保 Nginx 编译时启用了--with-http_fastcgi_module且配置未被覆盖 - 负载均衡环境多个 PHP 实例共享 session 存储时，各实例的
session.gc_maxlifetime必须一致，否则部分节点会提前清理 session
Redis 存储 session 时怎么设超时
当使用 session.save_handler = redis，仅靠 session.gc_maxlifetime 不足以保证自动过期，因为 Redis 本身不执行 PHP 的 GC 流程。必须显式设置 Redis key 的 TTL：
- 在 php.ini 中加：
session.save_path = "tcp://127.0.0.1:6379?database=0&password=&prefix=PHPSESSID:&timeout=2.5&retry_interval=1"—— 这里的 timeout 是连接超时，不是 key 过期 - 真正控制 key 过期的是
session.gc_maxlifetime，Redis 扩展会在写入 session 时自动调用EXPIRE，前提是该值大于 0 且扩展版本 ≥ 5.0.2 - 验证方法：用
redis-cli查看 key：TTL PHPSESSID:abc123，输出应接近session.gc_maxlifetime的剩余值
跨语言或跨框架共享 session 时，别假设其他系统也遵守 PHP 的 GC 规则——Redis TTL 才是唯一可依赖的硬性约束。
