Session过期由session.gc_maxlifetime（服务端清理依据）和session.cookie_lifetime（客户端Cookie有效期）共同决定，ThinkPHP的session.expire仅影响后者，不控制服务端GC；精确过期需用Redis/数据库等自定义驱动。
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：控制浏览器里PHPSESSIDCookie 的存活时间，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] 是合理的；但如果想“用户每操作一次就重置服务端过期时间”，仅靠这个配置做不到。
立即学习“PHP免费学习笔记（深入）”；
- 修改位置：通常在
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 还有效，但服务端已无对应数据，表现为“登录态突然消失”。
