最轻量在线人数统计：用flock()加锁配合时间戳会话列表
想在PHP项目中实现一个轻量级的在线人数统计功能？基于文件存储的方案，其核心思路非常明确：利用flock()函数进行文件锁控制，配合一个记录“会话ID|时间戳”的列表，并在每次统计前清理过期条目。这种方法比直接操作Session或引入数据库要便捷得多，尤其适合访问量不大的小型项目。当然，它也存在明确的性能上限。
为什么不能直接 file_get_contents() 后 ++ 再写回去？
一个常见的误解是：读取文件、数字加一、再写回文件，三步即可完成。问题的关键在于PHP的多进程环境——这个操作不具备原子性。设想一下，两个并发请求几乎同时读取到数字“12”，各自加1后写回，最终结果会是“13”而非正确的“14”。数据就这样丢失了。
因此，引入锁机制是必须的。但如何正确加锁呢？
flock($fp, LOCK_EX)是实现跨请求互斥访问的可靠方法。需要注意的是，file_put_contents(..., LOCK_EX)这个参数仅对单次写入操作本身加锁，并不能保护“读取-修改-写入”这个完整流程的线程安全。- 文件句柄的打开状态必须持续到整个操作完成并解锁。如果采用“打开→读取→关闭→再打开→写入→关闭”的模式，中间的关闭操作会释放锁，导致保护失效。
- 一个实用的优化建议是：将锁文件（例如
online.lock）与存储实际数据的计数文件（例如online.count）分开，这样可以有效降低读写冲突的概率。
如何存储才能准确判断“用户是否在线”？
仅仅存储一个计数器，只能回答“当前有多少个计数”，却无法区分这些是真实活跃的用户，还是已经离开但页面未关闭的“僵尸”会话。因此，我们需要一个能够识别“活性”的方案。
答案是存储带时间戳的会话列表，并基于有效期进行过滤。
- 记录格式：每条记录采用
session_id|timestamp的格式，例如abc123|1717025688。 - 在线判定：设定一个有效期（例如5分钟）。判断逻辑是：当前时间减去记录中的时间戳是否小于等于300秒。超过此时限的记录，将被视为过期并自动剔除。
- 写入优化：使用
file_put_contents($file, $line . “\n”, FILE_APPEND | LOCK_EX)来追加新记录。这种方式比每次重写整个文件要高效得多。 - 定期清理：清理过期记录的逻辑，必须在每次执行统计前触发。否则，文件会无限制增长，导致
file()读取速度越来越慢，最终影响整体性能。
最轻量在线人数统计需用flock()加锁配合时间戳会话列表：每条记录为“session_id|timestamp”，按5分钟有效期过滤，追加写入并每次统计前清理过期项，避免竞态与僵尸用户。
实际代码实现中需要注意哪些关键点？
思路虽然清晰，但细节决定成败。以下几个关键点，任何一个处理不当都可能导致计数不准甚至功能失效。
- Session ID的获取：PHP在CLI命令行和Web服务器（SAPI）环境下，
session_id()的行为不同。在Web环境中，务必先调用session_start()，再获取session_id()，否则可能得到空值。 - 行尾换行符处理：使用
file()函数读取文件后，每一行的末尾都包含换行符（\n）。在explode(‘|‘， $line)之前，必须先用trim()处理掉它，否则可能分割出空数组元素，引发后续错误。 - 写入权限检查：写入文件前，务必检查磁盘空间和目标目录的写入权限。使用
is_writable(dirname($file))进行判断，可以有效避免因权限不足导致的静默失败。 - 时间戳比较逻辑：判断记录是否过期时，推荐使用
当前时间戳的方式，而不是time() - $ts > 300。前者能更好地避免整数溢出或负值带来的误判。
立即学习“PHP免费学习笔记（深入）”；
性能和可靠性的边界在哪里？
文件锁方案的优势在于简单轻量，但其性能瓶颈也很明显。它很难承受每秒10次以上的持续并发写入，文件锁本身会成为性能瓶颈。此外，flock()在NFS网络文件系统或某些特定的容器文件系统上可能无法正常工作。
- 适用场景：这个方案更适合单机部署、日活跃用户数在千级别以下的小型项目或内部管理工具。
- 升级信号：一旦发现
flock()返回false（获取锁失败）的频率显著升高，就说明锁争抢已经非常严重，是时候考虑迁移到Redis等专业的、支持原子操作的内存存储方案了。 - 性能优化：不要将统计计数逻辑直接放在每个页面的顶部。更好的做法是将其封装成一个独立的函数，例如
get_online_count()，并利用APCu等缓存工具，将结果缓存10秒左右。这样可以大幅减少对文件系统的直接I/O操作，提升响应速度。
总而言之，文件路径管理、锁机制、过期策略这三者构成了这个方案的铁三角。任何一环处理不当，统计数据的可信度就会大打折扣。特别是时间戳校验，如果服务器系统时间与PHP中通过date_default_timezone_set()设置的时区不一致，很可能导致大批活跃用户记录被错误地清理掉，这点需要格外警惕。
