php 8.5 中 session.gc_probability 不起作用的主因是：未实际使用 files handler、gc_probability 与 gc_divisor 配对错误、时间戳或 gc_maxlifetime 设置异常、gc 本身为请求时概率触发且非后台进程，以及 gc_probability 在 php 8.5 中改为 int 类型导致小数被截断为 0。
php8.5 中 session.gc_probability 不起作用？先看 PHP 是否真在用 file handler
PHP 8.5 默认仍用 files 作为 session.save_handler，但 gc 概率失效的头号原因是：你其实没在用文件存储——比如启用了 Redis、Memcached 或数据库 session 扩展。这些 handler 完全不读 session.gc_probability 和 session.gc_divisor，gc 逻辑由后端服务自己管。
实操建议：
- 运行
var_dump(ini_get('session.save_handler'));确认值是files，不是redis、memcached等 - 检查
phpinfo()页面里 “Loaded Configuration File” 路径，确认修改的是正在生效的php.ini，不是某个被忽略的.ini片段 - CLI 和 FPM 的配置文件可能不同，
php -i | grep 'Loaded Configuration'和php-fpm -i | grep 'Loaded Configuration'要分别查
设了 session.gc_probability = 1 还是不触发 GC？注意 session.gc_divisor 是分母
session.gc_probability 单独设成 1 没用，它必须和 session.gc_divisor 配合算概率：gc_probability / gc_divisor。默认是 1/100，也就是 1%。设 gc_probability = 1 但 gc_divisor = 1000，实际概率就掉到 0.1%。
常见错误现象：改完 gc_probability 没效果，一查 gc_divisor 被其他配置（如 Docker 镜像预设、PaaS 平台覆盖）悄悄设成了 1000 或 0。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 在代码开头加
var_dump([ini_get('session.gc_probability'), ini_get('session.gc_divisor')]);，别只信配置文件 - 要确保概率生效，推荐显式配对：设
session.gc_probability = 1同时设session.gc_divisor = 100，避免除零或整数截断（gc_divisor为 0 会禁用自动 GC） - 若需每请求都检查过期 session，可设
session.gc_probability = 1且session.gc_divisor = 1，但仅限开发环境——线上高并发下会明显拖慢首字节响应
为什么本地开发能触发 GC，上生产就完全不动？时间戳权限和 session.gc_maxlifetime 错配
GC 触发时，PHP 会扫描 session.save_path 下所有 session 文件，比对文件修改时间（filemtime）和当前时间减去 session.gc_maxlifetime。如果服务器时间不准、NFS 挂载点不支持精确 mtime、或者 gc_maxlifetime 设得极大（比如 31536000 秒=1年），GC 就几乎不会删任何文件。
使用场景：容器化部署中，宿主机和 PHP 容器时区/时间不同步；或用了 cgroup 限制 CPU 导致系统调用延迟，filemtime 返回异常值。
实操建议：
- 执行
date和php -r "echo time() - filemtime(ini_get('session.save_path').'/sess_'.uniqid());"（先生成一个 session 文件再测），确认时间差计算合理 -
session.gc_maxlifetime必须和应用层 session 过期逻辑一致。比如 Cookie 过期设了 30 分钟，这里也应设1800，否则 GC 永远不清理 - Linux 上检查
session.save_path目录是否挂载自 NFS/CIFS：这类文件系统常返回缓存的 mtime，导致 GC 误判“文件很新”
PHP 8.5 的 session GC 本质是“请求时概率触发”，别指望它准时清理
PHP 的 session GC 不是后台守护进程，也不走 cron。它只在每次 session_start() 时，按概率决定是否扫一遍 save_path。这意味着低流量站点可能几小时都不触发一次，而高流量接口可能一秒触发多次。
性能影响：GC 扫描是阻塞式 I/O，save_path 下 session 文件越多、磁盘越慢，单次 GC 延迟越明显。PHP 8.5 没优化这个路径，只是把旧版的 rand() 换成更可靠的随机源。
实操建议：
- 生产环境别依赖内置 GC 清理。用
find /var/lib/php/sessions -name 'sess_*' -mmin +30 -delete配 cron 更可控（注意文件锁和并发删除风险） - 若必须用内置 GC，把
session.save_path设为独立 SSD 分区，避免和日志、数据库混在同一个慢盘上 - PHP 8.5 开始，
session.gc_probability改为 int 类型（不再接受 float），传小数会被截断为 0 —— 这个隐式转换容易被忽略
事情说清了就结束
