Session过期不生效需匹配session.gc_maxlifetime与ThinkPHP的'expire'配置，且Redis驱动需确保TTL写入、前端应配合心跳续期。
Session过期时间不生效？检查session.gc_maxlifetime和session.cookie_lifetime是否匹配
ThinkPHP本身不直接控制Session的底层过期逻辑，它依赖PHP原生的Session机制。常见现象是：明明在config/session.php里设了'expire' => 3600，但用户10分钟没操作就掉线了——大概率是PHP的gc_maxlifetime更短，触发了垃圾回收清理。
-
session.gc_maxlifetime（单位秒）决定服务端Session文件/存储项最多存活多久，ThinkPHP的'expire'必须≤它才有效 -
session.cookie_lifetime（单位秒）控制浏览器Cookie有效期；设为0表示关闭时失效，设为正数才会写入Expires时间 - 若用Redis等驱动，还需确认Redis自身的key过期时间是否与PHP配置对齐，比如
redis.session_expire扩展参数或手动SETEX
ThinkPHP中'expire'配置只在首次启动Session时起作用
ThinkPHP的config/session.php里'expire'字段不是动态刷新的计时器，它只影响session_start()时设置的gc_maxlifetime和Cookie过期时间。用户已登录后，再改这个值不会让现有会话延长。
- 修改后需重启Web服务器（如Apache/Nginx）或至少清空
runtime/session/目录（文件驱动下）才能生效 - 若想实现“用户活跃即续期”，得靠每次请求时手动调用
session_regenerate_id(true)或更新Session数据触发Redis key重设TTL - 注意：频繁
regenerate_id可能引发并发请求丢失Session，建议配合session_write_close()使用
Redis驱动下Session超时不工作？检查handler_options里的timeout和prefix
用Redis存Session时，ThinkPHP默认不会自动给每个key设置过期时间，而是依赖Redis自身的SETEX行为或PHP内置的redis扩展处理。如果发现Session永不超时或立刻消失，大概率是驱动配置没对上。
- 确保
handler_options中包含'timeout' => 3600（单位秒），这是Redis连接超时，不是Session超时，别混淆 - Session实际TTL由
session.gc_maxlifetime+ Redis驱动的写入逻辑共同决定；官方think-swoole或redis扩展通常会在写入时带EX参数，但自定义驱动容易漏掉 - 若用
phpredis扩展，确认启用redis.session_expire（ini配置），否则即使gc_maxlifetime设了，Redis也不会自动过期key
前端无操作自动登出？别只靠Session，加个心跳接口+客户端倒计时更可靠
纯依赖Session超时做“静默登出”体验很差：用户切到别的标签页，回来时突然403；或者网络延迟导致最后请求没触发续期，提前踢出。真实项目里，Session只是兜底，主动控制得靠前后端配合。
立即学习“PHP免费学习笔记（深入）”；
- 前端用
setTimeout监听用户操作，每5分钟发一次/api/keepalive，后端仅更新$_SESSION['last_active']并返回剩余秒数 - 后端在
App\Middleware\SessionCheck里检查time() - $_SESSION['last_active'] > 1800，超时则session_destroy()并返回401 - 避免把所有逻辑堆在
session_start()里——PHP Session锁会阻塞并发请求，心跳接口务必调用session_write_close()
Session超时机制真正难的不是配哪个参数，而是厘清「PHP原生机制」「ThinkPHP封装层」「存储驱动行为」「前端交互节奏」这四层各自管什么。少一层对齐，就会出现“明明设了2小时，结果15分钟就失效”的情况。
