必须用 sudo crontab -e 编辑 root 任务，因普通用户无权删除 /var/log、/tmp 等系统目录文件，且 cron 静默丢弃 stderr；脚本需指定解释器、用绝对路径命令、基于 -mtime 可靠清理、加日志与文件锁。
必须用 sudo crontab -e 编辑 root 任务，普通用户 crontab 无法删除 /var/log、/tmp 等系统目录下的文件，脚本会静默失败。
为什么不能用普通用户 crontab 清理系统文件
常见错误是写 0 2 * * * /usr/local/bin/clean.sh，结果脚本里 /bin/rm /var/log/nginx/*.log 总是没反应——因为权限不够，rm 返回 Permission denied，但 cron 默认丢弃 stderr，你看不到任何提示。
sudo rm 在 cron 下无效：没有交互式终端，不会弹密码框，直接卡住或退出码非零但无日志。
- 所有清理系统路径（如
/var/log、/tmp、/backup）的任务，必须走sudo crontab -e - 不要在 crontab 行里加
sudo，也不要用crontab -u root -e（部分系统不支持） - 验证方式：运行
sudo crontab -l，确认你编辑的是 root 的任务列表
脚本必须显式声明解释器并用绝对路径调用命令
cron 默认用 /bin/sh 执行，且 $PATH 极窄（通常只有 /usr/bin:/bin），python3、date -d、jq 都找不到；脚本里只写 find 或 echo 很可能失败。
- 脚本第一行必须是
#!/bin/bash（或#!/usr/bin/env bash） - crontab 条目中显式调用解释器：
0 2 * * * /bin/bash /usr/local/bin/clean.sh - 所有外部命令优先用绝对路径：
/usr/bin/find、/bin/rm、/usr/bin/date - 测试前先模拟 cron 环境：
env -i /bin/bash --noprofile --norc /usr/local/bin/clean.sh，这能暴露绝大多数路径和变量问题
清理逻辑别依赖文件名日期，要用 -mtime 或 -mmin
靠解析 backup_20240501.tar.gz 字符串判断过期，极易出错：文件被 touch 修改时间、命名不规范、时区错位，都会导致该删不删或误删。
- 更可靠的方式是基于文件最后修改时间：
/usr/bin/find /backup -type f -name "*.tar.gz" -mtime +7 -delete（注意：-mtime +7= 大于 168 小时，即第 8 天起） - 加
-daystart让时间计算从当日 00:00 开始，避免因执行时间浮动延迟一天：-daystart -mtime +7 - 调试阶段务必先用
-print或-ls替代-delete，确认列出的确实是目标文件 - 限定作用范围：
-maxdepth 1防止递归进子目录误删；-type f明确只处理文件
日志和锁机制不能省，否则失败无声、并发冲突
没有日志，脚本失败你看不到；没有锁，多个定时任务同时跑可能删掉正在写的日志或清空一半的缓存。
- 每行 cron 必须重定向输出：
0 2 * * * /usr/local/bin/clean.sh >> /var/log/clean.log 2>&1 - 加简单文件锁防止并发：
if [ -f /tmp/clean.lock ]; then exit 1; else touch /tmp/clean.lock; trap 'rm -f /tmp/clean.lock' EXIT; - 清理脚本末尾记得删锁文件，或用
trap保证异常退出时也释放 - 日志路径要确保可写，比如
/var/log/clean.log需root:syslog权限且chmod 644
真正容易被忽略的不是语法，而是环境隔离和时间语义：cron 的 $PATH 和 shell 是硬编码的，-mtime +7 不是“保留最近 7 天”，而是“删掉 7×24 小时之前修改的所有文件”——这个边界值在跨天任务中经常引发误删。
