必须用 sudo crontab -e 编辑 root 任务，因普通用户无权删系统目录文件；脚本需绝对路径、显式解释器、环境隔离、日志与锁机制，并用 -mtime +7 等可靠时间判断逻辑。
crontab 任务必须用 root 权限编辑
普通用户 crontab 没法删 /var/log、/tmp 或其他系统目录下的文件，脚本会静默失败。直接运行 crontab -e 编辑的是当前用户任务，而清理系统级文件必须走 sudo crontab -e。
常见错误：在普通用户下写 0 2 * * * /usr/local/bin/clean.sh，结果脚本里 /bin/rm /var/log/nginx/*.log 总是没反应——因为权限不够，rm 返回 Permission denied 但被 cron 丢弃了（没重定向输出）。
- 始终用
sudo crontab -e编辑 root 任务 - 别在 crontab 行里加
sudo：sudo rm在 cron 下无效，不会弹密码提示，直接卡住或失败 - 脚本里所有路径必须绝对化：
/bin/find、/usr/bin/python3，不能只写find
脚本开头要显式声明解释器并隔离环境
cron 默认用 /bin/sh 执行，且 $PATH 极窄（通常只有 /usr/bin:/bin），很多命令如 date -d、python3、jq 都找不到。
实操建议：
- 脚本第一行必须是
#!/bin/bash（或#!/usr/bin/env bash），且 crontab 中显式调用：0 2 * * * /bin/bash /usr/local/bin/clean.sh - 测试前先模拟 cron 环境：
env -i /bin/bash --noprofile --norc /usr/local/bin/clean.sh，这能暴露绝大多数路径和变量问题 - 所有外部命令优先用绝对路径：
/usr/bin/find、/bin/rm、/usr/bin/date
清理逻辑别依赖文件名日期，要用 -mtime 或 -daystart
靠解析 backup_20240501.tar.gz 里的字符串判断过期，极易出错：文件被 touch 修改时间、命名不规范、时区错位，都会导致该删不删或误删。
更可靠的方式是基于文件最后修改时间（即实际备份/写入完成时间）：
-
/usr/bin/find /backup -type f -name "*.tar.gz" -mtime +7 -delete：删 7 天前修改的文件（注意：-mtime +7= 大于 168 小时，不是“第 7 天当天”） - 加
-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; else touch /tmp/clean.lock; trap "rm -f /tmp/clean.lock" EXIT; - 清理内核缓存等敏感操作，建议记录前后内存状态：
free -h >> /var/log/clean.log前后各一次 - 对
/proc/sys/vm/drop_caches这类操作，必须确保脚本以 root 权限运行，且写入前检查可写：test -w /proc/sys/vm/drop_caches || exit 1
真正容易被忽略的是环境隔离和时间语义——-mtime +7 和你脑子里想的“7天前”不是一回事，而 env -i 测试那一步，90% 的人跳过，然后花半天查为什么脚本手动能跑、cron 就不动。
