仅改session.gc_maxlifetime基本没用，必须同步设置session.cookie_lifetime且两者值一致；否则客户端Cookie丢失导致Session ID无法传递，服务器端保留再久也无效。
直接说结论：仅改 session.gc_maxlifetime 基本没用，必须同步调整 session.cookie_lifetime，且两者值要一致；否则浏览器端 Cookie 一丢，Session ID 就传不过来，服务器再长的保留时间也白搭。
为什么改了 session.gc_maxlifetime 还是 24 分钟就失效
因为 PHP 的 Session 生效依赖「两端匹配」：服务器存多久（gc_maxlifetime） + 客户端记多久（cookie_lifetime）。默认 cookie_lifetime = 0，意味着关浏览器就删 Cookie → 下次请求没 PHPSESSID → 服务器只能新建会话。你改了服务端时间，但客户端早把 ID 弄丢了，自然无效。
常见错误现象：
- 明明
ini_set('session.gc_maxlifetime', 3600)了，用户切个标签页回来就登出 -
phpinfo()显示gc_maxlifetime是 3600，但实际 session 文件 24 分钟后就被gc清掉了（说明配置没生效或被覆盖）
必须同时设置 session.cookie_lifetime 和 session.gc_maxlifetime
这两个值不光要设，还得设成一样，且要在 session_start() 前完成。顺序错了、时机晚了，都会失败。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 用
session_set_cookie_params()设置 Cookie 生命周期（推荐），例如：session_set_cookie_params([ 'lifetime' => 3600, 'path' => '/', 'domain' => '', 'secure' => true, // 生产环境 HTTPS 必开 'httponly' => true, 'samesite' => 'Lax' ]); session_start(); - 或者用
ini_set()（注意：必须在session_start()前）：ini_set('session.gc_maxlifetime', 3600); ini_set('session.cookie_lifetime', 3600); session_start(); - 若用 Nginx + PHP-FPM，确保
php.ini或.user.ini中的设置未被覆盖（检查phpinfo()输出的实际值）
ThinkPHP 等框架里为什么改了配置还不生效
框架通常在底层封装了 session_start()，你改 ini_set() 的时机很可能晚于框架启动 Session 的时间。比如 ThinkPHP 5.1 默认在应用初始化阶段就调用了 session_start()，之后再改参数完全无效。
解决路径：
- 在框架入口文件（如
public/index.php）最开头就调用session_set_cookie_params()和ini_set() - ThinkPHP 用户可改配置项：
'session' => ['expire' => 3600]（但仅对框架内管理的 session 生效，不改变原生 PHP 行为） - 更可靠的方式：直接换存储引擎，比如设
session.save_handler = redis，Redis 的过期由自身 TTL 控制，不受 PHPgc干扰
容易被忽略的权限与路径陷阱
即使参数全对，Session 仍可能“看似过期”——其实是根本没存进去。
关键检查点：
- 确认
session.save_path目录存在且 Web 进程（如www-data）有写权限：ls -ld /var/lib/php/sessions - 如果用宝塔、Docker 或共享主机，
save_path可能被强制重定向到项目目录下，需手动赋权：chmod 770 /path/to/your/session/dir - Linux 系统上注意 SELinux 或 AppArmor 限制，有时
setsebool -P httpd_can_network_connect 1才能让 PHP 连 Redis
真正卡住人的，往往不是参数设错，而是 session_start() 没执行、输出已提前、Cookie 被拦截、或者目录权限死锁——这些比调时间更常导致“过期假象”。
