如何在ThinkPHP中设置Session过期时间_expire配置与垃圾回收机制-ThinkPHP-PHP中文网

session过期由session.gc_maxlifetime（服务端清理依据）和session.cookie_lifetime（客户端cookie有效期）共同决定，thinkphp的session.expire仅影响后者，不控制服务端gc；精确过期需用redis/数据库等自定义驱动。

如何在thinkphp中设置session过期时间_expire配置与垃圾回收机制

Session 过期时间由 `session.gc_maxlifetime` 和 `session.cookie_lifetime` 共同决定

ThinkPHP 本身不直接控制 Session 的实际过期逻辑，它依赖 PHP 原生的 Session 机制。你改 session.expire 配置项（比如设为 3600），只是让框架在写入 Session 时顺手调用 session_set_cookie_params() 设置 Cookie 过期时间，但服务端 Session 文件是否被删除，完全看 PHP 的 gc_maxlifetime。

常见错误现象：session.expire 设了 5 分钟，但用户 10 分钟没操作还能登录——说明服务端 Session 文件没被清理；或者刚设完就登出——可能是 cookie_lifetime 为 0（浏览器关闭即失效）且用户没关标签页。

session.gc_maxlifetime（单位秒）：PHP 内部判断 Session 文件“是否该删”的唯一依据，必须 >= 你期望的过期时间
session.cookie_lifetime：控制浏览器里 PHPSESSID Cookie 的存活时间，0 表示会话级（关浏览器即丢）
ThinkPHP 的 session.expire 配置只影响后者，不影响前者

ThinkPHP 5.1+ 中 `session.expire` 配置的实际作用范围

这个配置只在初始化 Session 时生效，也就是 session_start() 前调用 session_set_cookie_params()。它不会动态延长已有 Session 的有效期，也不会触发服务端刷新。

使用场景：用户登录后想让 Cookie 保持 2 小时，但服务端仍按 24 小时清理（gc_maxlifetime=86400），这时设 'session' => ['expire' => 7200] 是合理的；但如果想“用户每操作一次就重置服务端过期时间”，仅靠这个配置做不到。

修改位置：通常在 config/session.php 或应用配置中
对 CLI 环境无效（无 Cookie 概念）
若启用 session.use_strict_mode = 1（推荐），旧 Session ID 会被拒绝，此时 expire 只影响新生成的 Cookie

垃圾回收（GC）不触发的三个典型原因

PHP 的 Session GC 是概率性触发的，不是定时任务。哪怕 gc_maxlifetime 设得很短，也可能长时间不清理旧文件，导致“明明过期了却还能用”。

常见错误现象：手动删了 session.save_path 下的文件，重启服务后又出现相同问题；或日志里完全看不到 GC 执行痕迹。

session.gc_probability 和 session.gc_divisor 共同决定 GC 触发概率（默认 1/100），每次请求都有可能但不保证执行
Web 服务器用的是 FPM 模式时，GC 只会在 PHP-FPM worker 进程处理请求时随机发生，静态资源请求（如 .js/.css）通常不触发
如果 session.save_path 权限不对（如 nginx 用户无法写入），GC 会静默失败，文件越积越多

真正可控的过期方案：用数据库存 Session + 主动校验

当业务要求“精确控制过期”“支持强制踢出”“跨机器一致”，必须绕开原生文件 GC。ThinkPHP 支持自定义 Session 驱动，推荐用数据库（如 MySQL）或 Redis。

使用场景：后台管理系统需实时下线某用户、多节点部署、审计登录状态。

Redis 方案：设置 key 过期时间（SETEX session:xxx 3600 {...}），天然支持自动清理
数据库方案：表里加 expire_time 字段，每次读 Session 前先查 WHERE expire_time > NOW()
无论哪种，都要在 think\Session 初始化时传入驱动类，并确保 session.auto_start = false（避免框架提前启动原生 Session）

容易被忽略的一点：即使用了 Redis，也要注意客户端 Cookie 的 Max-Age 是否同步更新——否则用户可能 Cookie 还有效，但服务端已无对应数据，表现为“登录态突然消失”。