用 find + crontab 是最轻量、最可控的日志清理方案，但需避免 -mtime +15 误判——它匹配修改时间早于16整天前的文件，而非15天整；推荐按文件名中 yyyy-mm-dd 日期字符串比对删除。
直接上结论：用 find + crontab 是最轻量、最可控的方案，但必须避开 -mtime +15 的常见误判陷阱——它不是“删除15天前的文件”，而是“删除修改时间早于 15×24 小时之前的文件”，实际可能漏删或错删。
为什么 -mtime +15 容易出错
-mtime 基于文件的 modify time（内容最后修改时间），而日志文件往往在写入后不再更新，但滚动、重命名、logrotate 归档等操作会改变这个时间戳。更关键的是：+15 表示“严格大于 15 天”，即至少 16 整天，不是“15 天整”。比如今天是 7 月 9 日 12:45，find -mtime +15 实际匹配的是 6 月 23 日 12:45 之前修改的文件——你本想删 6 月 24 日及更早的，结果 6 月 24 日 00:00–12:44 的文件全被放过。
- 日志文件名带日期（如
app-2026-06-24.log）时，-mtime和文件名不一致，靠名字删更准 - 应用自己按天生成日志但不轮转（如每小时追加写入同一文件），
-mtime只反映最后一次写入时间，无法体现“该文件属于哪天” - logrotate 启用
dateext后，归档文件的-mtime是归档时刻，不是原始日志日期
推荐做法：按文件名中的日期字符串清理
适用于日志文件名含 YYYY-MM-DD 或 YYYYMMDD 格式（如 access-2026-06-24.log、error20260624.txt）。脚本先算出“半个月前”的日期阈值，再用 grep 提取并比较：
#!/bin/bash
LOG_DIR="/var/log/myapp"
RETENTION_DAYS=15
THRESHOLD=$(date -d "$RETENTION_DAYS days ago" +%Y-%m-%d 2>/dev/null || date --date "$RETENTION_DAYS days ago" +%Y-%m-%d)
<p>cd "$LOG_DIR" || exit 1
for f in *.log; do
[[ -f "$f" ]] || continue</p><h1>提取 YYYY-MM-DD 格式日期</h1><p>date_in_name=$(echo "$f" | grep -oE '[0-9]{4}-[0-9]{2}-[0-9]{2}')
if [[ -n "$date_in_name" && "$date_in_name" </p>
- 兼容 CentOS/RHEL（
date -d）和 Ubuntu/Debian（date --date） - 用字符串比较
判断日期先后，比时间戳转换更简单可靠 - 只处理
.log文件，避免误删目录或非日志文件 - 加
[[ -f "$f" ]]防止通配符无匹配时误删当前目录下所有文件
如果必须用 -mtime，请这样调用
仅当确认日志文件每天新建、不复写、且修改时间可信时才用。把 +15 改成 +14 才接近“半个月前”：
-
find /var/log/myapp -type f -name "*.log" -mtime +14 -exec rm -f {} \;→ 删除修改时间 ≥ 15 天前的文件（即 6 月 24 日及更早） - 加
-type f避免误删目录（rm -rf风险太高，改用rm -f） - 加
-print先预览：find /var/log/myapp -type f -name "*.log" -mtime +14 -print，确认无误再执行删除 - 不要用
rm -rf，日志文件都是普通文件，rm -f足够且安全
别忘了加到 crontab 并验证权限
脚本保存为 /usr/local/bin/clean-old-logs.sh，然后：
chmod +x /usr/local/bin/clean-old-logs.sh-
crontab -e加入：30 2 * * * /usr/local/bin/clean-old-logs.sh >> /var/log/clean-logs.log 2>&1（每天凌晨 2:30 执行） - 确保 cron 运行用户（通常是 root）对
LOG_DIR有读写权限 - 首次运行前手动执行一次，检查日志输出和实际删除效果
真正容易被忽略的点是：日志路径是否跨文件系统、是否有 NFS 挂载点、以及 find 在大目录下执行缓慢导致 cron 任务堆积——建议在脚本开头加 timeout 300 限制最长运行 5 分钟。
