PHP 8.0会话过期误判源于服务端GC、客户端Cookie、应用层时间戳三者不同步；需统一session.gc_maxlifetime与session.cookie_lifetime，正确调用session_set_cookie_params()，并强制在所有请求入口校验$_SESSION['last_activity']。
PHP 8.0 中会话过期误判，本质是「服务端 GC 时间、客户端 Cookie 过期、应用层时间戳校验」三者不同步导致的。最典型现象是：用户明明刚操作，页面却突然跳登录页；或设置 2 小时，实际 5 分钟就失效。这不是 Bug，而是配置错位。
session.gc_maxlifetime 和 session.cookie_lifetime 必须一致
PHP 8.0 默认 session.gc_maxlifetime 是 1440 秒（24 分钟），session.cookie_lifetime 默认为 0（浏览器关闭即失效）。两者不匹配时，会出现「Cookie 还在但服务端数据已被删」或「服务端数据还在但 Cookie 已丢」。
- 若你希望会话维持 1 小时，必须同时设：
session.gc_maxlifetime = 3600和session.cookie_lifetime = 3600 - 修改后必须重启 PHP-FPM 或 Apache/Nginx，
reload不生效；Docker 容器需重建或 exec 进入改配置再重启服务进程 - 用
phpinfo()检查当前值，避免被云平台（如 Laravel Forge、Cloudways）的运行时覆盖层静默覆盖
session_set_cookie_params() 要在 session_start() 前调用
动态设置 Cookie 参数时，session_set_cookie_params() 的调用时机极易出错。它只影响本次请求生成的 Cookie，且必须在 session_start() 之前执行，否则无效。
- 错误写法：
session_start(); session_set_cookie_params(...);—— 此时 Cookie 已发，参数被忽略 - 正确顺序：
session_set_cookie_params(3600, '/', '', true, true); session_start(); - 注意第 4、5 个参数：
true表示Secure和HttpOnly，生产环境建议开启；若本地开发用 HTTP，第 4 个参数需设为false，否则 Cookie 不会被发送
手动时间戳校验必须覆盖所有入口点
仅靠 GC 和 Cookie 无法精准控制「空闲超时」，尤其在长连接、AJAX 轮询、单页应用（SPA）中，GC 不触发、Cookie 不刷新，但用户实际已离开。此时必须用 $_SESSION['last_activity'] 主动判断。
立即学习“PHP免费学习笔记（深入）”；
- 每次
session_start()后立即检查：if (isset($_SESSION['last_activity']) && time() - $_SESSION['last_activity'] > 1800) - 销毁逻辑要完整：
session_unset(); session_destroy(); setcookie(session_name(), '', time() - 3600, '/');—— 否则旧 Cookie 可能继续带 ID 发起请求，造成「假登录」 - 所有受保护页面（包括 API 接口、AJAX 后端脚本）都必须包含该检查；漏掉一个
data.php或upload.php，就可能绕过超时控制
Redis 存储时 gc_maxlifetime 失效，必须靠 TTL
若项目使用 Redis 存储 Session（如通过 session.save_handler = redis），PHP 的 gc_maxlifetime 机制完全不工作 —— Redis 自身不执行 GC，全靠 setex 设置键的 TTL。
- 确认
session.save_path是否含ttl=3600，例如：tcp://127.0.0.1:6379?database=2&password=&prefix=phpsess:&ttl=3600 - 若用自定义 Redis handler 类，确保
write()方法中调用了$redis->setex($id, $ttl, $data)，而非set() - ThinkPHP、Laravel 等框架的 Session 驱动通常已封装 TTL，但需核对框架配置项（如 TP 的
'expire' => 3600）是否与 Redis 的ttl参数一致
真正容易被忽略的是：**GC 触发概率本身不可控** —— 即使 gc_maxlifetime 设为 3600，PHP 仍按 gc_probability/gc_divisor 随机决定是否清理，所以不能依赖它做精确超时。只要业务对空闲时长敏感，就必须用时间戳校验，且这个逻辑得跑在每个请求的最开头，连 favicon.ico 请求都不能放过。
