判断用户是否在线需记录最后活跃时间而非仅依赖session存在，每次请求更新$_SESSION['last_active']或Redis中带过期的键，检查时对比当前时间与该时间戳差值是否超阈值。
PHP 怎么用 session 判断用户是否在线
直接靠 $_SESSION 本身不能判断“在线”，因为 session 默认只在用户关闭浏览器后才过期（实际由 session.cookie_lifetime 和 session.gc_maxlifetime 共同决定），而用户可能只是闲置没操作。真正可行的做法是：每次用户发起请求时，更新一个“最后活跃时间”字段，并设定合理的超时阈值（比如 5 分钟）。
常见错误是把 session_start() 后直接读 $_SESSION['user_id'] 当作“在线”，这只能说明 session 没销毁，不代表用户当前正在操作。
- 必须在每次登录成功或有效请求中执行：
$_SESSION['last_active'] = time(); - 检查在线状态时，不查 session 是否存在，而是查：
isset($_SESSION['last_active']) && (time() - $_SESSION['last_active'] - 注意 PHP-FPM 或 opcache 可能导致
$_SESSION读取延迟，建议搭配数据库或 Redis 存储活跃状态用于跨服务器校验
用 Redis 存储用户在线状态更可靠
单机用 session 不适合集群环境，Redis 是最常用的替代方案。核心逻辑是：用户登录后写入 redis->setex('online:user:123', 300, time())，每次心跳或请求都 expire 延长 TTL；查询时用 exists 或 get 判断键是否存在且未过期。
性能上，Redis 的 SETEX 和 EXISTS 都是 O(1)，比轮询数据库快得多；兼容性上，只要 PHP 装了 redis 扩展（不是 phpredis 这种旧名），就能直接用 Redis 类。
立即学习“PHP免费学习笔记（深入）”；
- 不要用
INCR或HSET存在线状态——它们不自带过期，得额外调EXPIRE，容易漏掉 - 键名建议带业务前缀，如
online:web:user:{$uid}，避免和其他模块冲突 - 如果前端需要实时推送在线状态，Redis 可配合
PUB/SUB，但注意它不保证消息送达，生产环境慎用
为什么不能只依赖数据库的 last_login 字段
users.last_login 是登录时间，不是最后活跃时间。用户可能登录后挂机 8 小时，last_login 依然不变，但它完全无法反映“此刻是否在线”。强行用它做在线判断，会导致大量误判。
更糟的是，频繁更新 last_login 或新增 last_active 字段到用户主表，会引发写锁、主从延迟、索引膨胀等问题，尤其在高并发场景下。
- 正确做法是单独建一张轻量表，如
user_online，字段仅需user_id（主键）、updated_at（自动更新），并设ON UPDATE CURRENT_TIMESTAMP - 查询语句应为：
SELECT 1 FROM user_online WHERE user_id = ? AND updated_at > DATE_SUB(NOW(), INTERVAL 5 MINUTE) - 记得给
updated_at加索引，否则全表扫描一碰就慢
前端怎么配合做“伪实时”在线提示
PHP 无法主动通知前端用户上线/下线，所以常见策略是前端定时轮询（如每 30 秒发一次 /api/v1/user/online?uid=123），后端返回布尔值或时间戳。别用 WebSocket 强撑——除非你整个系统已基于 Swoole 或 Workerman 构建，否则纯 PHP + Apache/Nginx 做不了长连接。
轮询看似土，但在多数管理后台或社交类页面中足够用；关键是控制频率和响应体积，避免压垮接口。
- 接口必须走缓存，比如用
apcu_fetch('online_status_'.$uid)先查 APCu，没命中再查 Redis - 返回格式尽量精简，例如只返回
{"online":true}，不要带多余字段或包装结构 - 用户关闭标签页时，可监听
beforeunload发个注销请求，但不可靠——网络中断、崩溃、强制关浏览器都会失败，只能当优化项，不能当核心逻辑
真正的难点不在“怎么存”，而在“什么时候删”。用户没登出就走，服务端没法感知连接断开，所有方案都得靠超时机制兜底。这个超时值（3 分钟？5 分钟？10 分钟？）要结合业务容忍度、存储成本、查询压力一起权衡，没有标准答案。
