session.gc_maxlifetime仅控制垃圾回收判定过期的阈值，非session_id有效期或用户无操作等待时长；实际清理由gc_probability和gc_divisor概率触发，且在redis等外部存储中被忽略。
直接改 php.ini 里的 session.gc_maxlifetime 不够用
改完 session.gc_maxlifetime 后 session 还是很快过期，不是配置没生效，而是 PHP 的垃圾回收（GC）根本没触发——它靠概率运行，不是定时执行。你设了 session.gc_maxlifetime = 86400（24 小时），但若 session.gc_probability 和 session.gc_divisor 仍是默认的 1/1000，那平均每 1000 次请求才清理一次。低流量站点可能一整天都不触发 GC，过期文件堆着不删；高流量站点又可能刚写入就被误删。
在 XAMPP 中定位并修改三个关键 GC 参数
XAMPP 的 php.ini 文件通常位于：C:\xampp\php\php.ini（Windows）或 /Applications/XAMPP/xamppfiles/etc/php.ini（macOS）。搜索以下三行并按需调整：
-
session.gc_maxlifetime：设为你期望的 session 数据“最后修改后还能活多久”，单位秒。例如登录态要维持 8 小时，就写session.gc_maxlifetime = 28800 -
session.gc_probability和session.gc_divisor：控制 GC 触发概率。XAMPP 默认常为1/100或1/1000。开发调试建议调成1/100（即每 100 次请求检查一次过期文件）；本地测试频繁操作时可临时设为1/10，避免反复登录 - 改完必须重启 Apache：XAMPP 控制面板点 Apache → Restart，不能只刷新页面
session.gc_probability = 0 是个危险操作
有人想“禁用 GC 避免误删”，就把 session.gc_probability = 0。这会导致过期 session 文件永久滞留 session.save_path 目录（通常是 C:\xampp\tmp 或 /Applications/XAMPP/xamppfiles/temp），几天后磁盘占满、session_start() 开始失败，错误信息可能是：Failed to write session data (files)。这不是 session 失效，是 PHP 根本写不进临时目录了。
真正需要长期会话，应该：
- 确认
session.save_path目录有写权限且空间充足 - 搭配
session_set_cookie_params(['lifetime' => 28800])延长 Cookie 有效期（注意：这仅影响客户端 Cookie 过期，不影响服务端文件生命周期） - 避免把
gc_maxlifetime设得过大（如 > 604800 / 7 天），否则低频访问用户 session 会长期占用磁盘
验证修改是否真正起效
光看 phpinfo() 页面显示的配置值没用，得观察实际行为：
- 打开
session.save_path目录，手动创建一个测试 session 文件：sess_abc123，内容随便写（如user_id|s:3:"100";），修改时间为 1 小时以前 - 用浏览器访问一个调用
session_start()的 PHP 脚本（哪怕只有一行），连续刷 100–200 次 - 再去看那个
sess_abc123文件是否还在。如果没了，说明 GC 已按新概率触发；如果还在，检查 Apache 是否真重启、有没有其他 php.ini 被优先加载（比如 .htaccess 或 user_ini.filename 覆盖） - 注意：GC 只删“最后修改时间 +
gc_maxlifetime
最易忽略的一点：XAMPP 默认启用 opcache.enable_cli=0，但 CLI 模式下运行的脚本（比如用命令行测 GC）不会触发 session GC——它只在 Web SAPI（如 Apache、FPM）中由请求驱动。别用 php test.php 测，得用浏览器或 curl 访问。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
