<p>可通过统计 session.savepath 目录下 sess* 文件数粗略估算活跃会话数，但需注意包含已过期未清理文件；精确统计需结合 gc_maxlifetime 与文件修改时间过滤，或查询 Redis/MySQL 等后端存储。</p>
怎么查看当前有多少活跃会话
PHP 默认不提供实时会话数量统计接口，但可以通过检查 session.save_path 目录下的文件数粗略估算。前提是使用默认的 files 存储处理器（session.save_handler=files）。
常见做法是用 shell 命令统计：
ls -1 $(php -r "echo ini_get('session.save_path');") | wc -l注意：ls -1 列出的是所有 sess_* 文件，包括已过期但尚未被 GC 清理的；实际活跃会话数通常更少。若需精确值，必须结合 session.gc_maxlifetime 和文件修改时间过滤。
- 会话文件名格式固定为
sess_<session_id>，可用find+-mmin筛选最近活跃的 - 若改用 Redis 或数据库存储，就得查对应后端：Redis 用
KEYS sess_*（生产禁用）或SCAN；MySQL 查SELECT COUNT(*) FROM sessions WHERE updated_at > DATE_SUB(NOW(), INTERVAL 1440 SECOND) - 不要依赖
session_status()或session_id()，它们只反映当前请求的会话状态，无法跨请求统计
如何记录每次会话的创建与销毁时间
PHP 原生不记录时间戳，需手动补全。最轻量的方式是在 session_start() 后立刻写入时间字段：
立即学习“PHP免费学习笔记（深入）”；
session_start();
if (!isset($_SESSION['created_at'])) {
$_SESSION['created_at'] = time();
}
$_SESSION['updated_at'] = time();这样每个会话在首次访问时打上创建时间，后续请求更新最后活动时间。但要注意：
- 不能只靠
$_SESSION['created_at']判断“新用户”，因为会话可能被复用（如 Cookie 未过期、用户没登出） - 销毁时不会自动清理这些字段，
unset($_SESSION['created_at'])或session_unset()才能清除 - 若启用了
session.use_strict_mode=1，旧会话 ID 被拒绝后会生成新会话，此时created_at是新的，逻辑上更干净
为什么 session.gc_maxlifetime 不等于实际会话存活时间
session.gc_maxlifetime 只控制服务器端会话数据的“理论过期阈值”，不是硬性截止时间。GC（垃圾回收）是否触发、何时触发，取决于三个条件同时满足：
-
session.gc_probability/session.gc_divisor的随机概率（例如1/100表示每次session_start()有 1% 概率启动 GC） - 当前请求的脚本执行时，
session.save_path下存在修改时间早于gc_maxlifetime秒的会话文件 - Web 服务器进程（如 Apache worker、PHP-FPM 进程）有权限读写
session.save_path目录
这意味着：一个会话可能在 gc_maxlifetime=1440（24 分钟）后仍存在于磁盘，直到某次恰好触发 GC 才被删除。监控时若发现大量“僵尸会话”，优先检查 gc_probability 是否太低，或 save_path 权限是否异常。
用 session_set_save_handler 自定义监控的边界在哪
想精准追踪会话生命周期，最终要接管存储逻辑。实现 SessionHandlerInterface 时，可在 read()、write()、destroy() 中埋点：
public function write($id, $session_data) {
error_log("SESSION WRITE: $id at " . date('c'));
return parent::write($id, $session_data);
}但要注意：
-
read()在session_start()早期就被调用，此时$_SESSION还未初始化，不能依赖它做判断 -
destroy()不代表用户主动登出，也可能是 GC 清理或超时失效，需结合$_SESSION内容或日志上下文区分 - 自定义 handler 若写入数据库，务必加索引到
session_id和updated_at字段，否则查询活跃会话会变慢
真正难监控的不是“谁在线”，而是“谁刚断开却没触发 destroy”——比如用户直接关浏览器、网络中断、或移动端切后台休眠。这类会话只能靠定期扫描 + 超时策略兜底，没有银弹。
