最稳妥清理PHP日志的方式是用find配合-mtime或-mmin定期执行，而非PHP内轮询；注意-mtime +7实为≥8天，精确控制应使用-mmin +10080，并先用-ls预览；logrotate才是生产环境首选方案。
find 命令配合 -mtime 清理过期日志文件最直接
Linux 环境下 PHP 应用产生的日志（如 access.log、error.log、laravel.log）通常由 Web 服务器或框架写入，PHP 自身不自动清理。最稳妥、低侵入的方式是用系统级 find 配合 cron 定期执行，而非在 PHP 脚本里轮询删除。
常见错误是误用 -mtime +7 认为“7 天前的文件”，实际它匹配的是“修改时间早于 7×24 小时前的文件”，且按天取整（忽略小时分钟），可能导致某天凌晨刚生成的日志被提前删掉。
-
find /var/log/myapp -name "*.log" -mtime +7 -delete：删 8 天前及更早修改的文件（注意：+7 表示 >7 天，即 ≥8 天） - 要精确到“7 天前 00:00 之后创建/修改的都保留”，改用
-mmin +10080（7×24×60=10080 分钟） - 首次运行前务必先去掉
-delete，加-ls预览将删哪些文件，避免误删 - 如果日志被 logrotate 切割，注意
find默认不进子目录；需加-maxdepth 1限制层级，或明确路径如/var/log/myapp/*.log
PHP 中用 glob + filemtime 手动清理需谨慎
某些部署环境不允许用 find（如共享主机、容器无权限），才考虑在 PHP 中实现。但必须避开 scandir() 全量读取再遍历的低效做法，也别用 RecursiveDirectoryIterator 处理深层嵌套——日志目录结构简单，没必要。
关键点是：PHP 进程用户必须对日志目录有读+执行（进入目录）权限，否则 filemtime() 报 Warning: filemtime(): stat failed；删除时还需写权限。
立即学习“PHP免费学习笔记（深入）”；
- 用
glob("/var/log/myapp/*.log", GLOB_NOSORT)获取文件列表，比scandir()快且天然过滤掉 . 和 .. - 对每个文件调用
filemtime($f)，与time() - 7 * 86400比较，不用strtotime("-7 days")（后者依赖时区，易出错） - 删除前加
is_writable($f)判断，失败则error_log("Cannot delete {$f}: not writable")，避免静默失败 - 单次最多删 100 个文件，防止超时；可结合
set_time_limit(30)控制脚本生命周期
Logrotate 是生产环境首选方案
如果你控制服务器配置，logrotate 不是“可选项”，而是标准实践。它解决的不只是清理，还包括压缩、归档、按大小/时间轮转、postrotate 脚本触发 reload 等完整生命周期管理。
典型坑是没配 create 导致新日志无法写入（权限丢失），或漏了 missingok 导致某天没日志就报错中断整个 rotate 流程。
- 配置示例：
/var/log/myapp/*.log { daily missingok rotate 30 compress delaycompress create 0644 www-data www-data sharedscripts postrotate if [ -f /var/run/nginx.pid ]; then kill -USR1 `cat /var/run/nginx.pid` fi endscript } -
rotate 30表示保留最近 30 个归档，不是“30 天”；真正控制过期的是daily+rotate组合 - 测试配置是否合法：运行
logrotate -d /etc/logrotate.d/myapp（-d 是 debug 模式，不真实执行） - 手动触发一次：
logrotate -f /etc/logrotate.d/myapp，观察/var/lib/logrotate/status更新
清理逻辑里最容易被忽略的其实是时间基准
所有基于时间的清理，核心都依赖一个“参考时间点”。find -mtime 用的是系统当前时间，logrotate 用的是 cron 触发时刻，而 PHP 的 time() 取的是 PHP 进程启动时的 $_SERVER['REQUEST_TIME_FLOAT'] 或 microtime(true) —— 如果你的 PHP 脚本跑在常驻进程（如 Swoole、Workerman）里，time() 可能始终不变，导致判断永远失效。
另一个隐藏问题是时区：Web 服务器、PHP、系统 cron 可能使用不同 TZ 设置。比如 PHP 设了 date.timezone = "Asia/Shanghai"，但系统 cron 按 UTC 运行，就会出现“计划删 7 天前的，结果删了 6 天前的”。
- 统一所有环节的时区：在 crontab 里显式声明
TZ=Asia/Shanghai，或在 PHP 脚本开头加date_default_timezone_set('Asia/Shanghai') - 避免用“今天减 N 天”这种模糊表述，全部换算成 Unix timestamp 比较（如
$cutoff = time() - 7 * 86400） - 日志文件名若含日期（如
app-2024-05-01.log），优先用文件名解析时间，比filemtime()更可靠（因为日志可能被 touch 过、或 NFS 时间不同步）
