必须用 sudo crontab -e 编辑 root 任务，因为普通用户 cron 权限受限无法删除 /var/log、/tmp 等系统目录文件，且 crontab 中加 sudo 无效；脚本需声明解释器、用绝对路径、加锁与日志，并用 -mtime 而非文件名判断过期。
必须用 sudo crontab -e 编辑 root 任务，普通用户 crontab 无法删除 /var/log、/tmp 等系统目录下的文件，脚本会静默失败。
为什么不能用普通用户 crontab 清理系统文件
普通用户执行 crontab -e 写的定时任务，运行时权限等同于该用户。而 /var/log/nginx/*.log、/var/lib/docker/containers/*/logs 这类路径下文件通常属主为 root 或服务用户（如 syslog），普通用户无权 rm 或 truncate。
常见现象是：脚本在终端手动运行成功，但放进普通用户的 crontab 后毫无反应——因为 rm 返回 Permission denied，而 cron 默认丢弃 stderr，你根本看不到错误。
- 别在 crontab 行里加
sudo：0 2 * * * sudo /bin/rm /var/log/*.log在 cron 下无效，不会弹密码提示，直接卡住或失败 - 必须用
sudo crontab -e，编辑的是 root 的 crontab，所有命令天然拥有 root 权限 - 验证方式：
sudo crontab -l能列出你的规则；crontab -l（不带 sudo）则只显示当前用户自己的规则
脚本必须显式声明解释器并用绝对路径调用
cron 默认用 /bin/sh 执行脚本，且环境变量极简：$PATH 通常只有 /usr/bin:/bin，没有 /usr/local/bin、/opt/xxx/bin，也找不到 python3、jq、date -d 等命令。
直接写 find /tmp -mtime +7 -delete 看似没问题，但若系统里 find 实际在 /usr/bin/find，而 /bin/sh 的 $PATH 里没这个路径，就会报 command not found。
- 脚本第一行必须是
#!/bin/bash（或#!/usr/bin/env bash），且 crontab 中显式调用：0 2 * * * /bin/bash /usr/local/bin/clean.sh - 所有外部命令优先用绝对路径：
/usr/bin/find、/bin/rm、/usr/bin/date，不依赖$PATH - 测试前务必模拟 cron 环境：
env -i /bin/bash --noprofile --norc /usr/local/bin/clean.sh，这能暴露 90% 的路径和变量问题
清理逻辑别依赖文件名日期，要用 -mtime 或 -mmin
靠解析 backup_20240701.tar.gz 里的字符串判断过期，极其脆弱：文件被 touch 修改时间、命名不规范（如 bk-2024-07-01.zip）、时区错位，都会导致该删不删或误删。
-mtime +7 表示“最后修改时间距今超过 168 小时”，即第 8 天及以后的文件——这是基于实际写入完成时间的可靠依据。
- 加
-daystart让计算从当日 00:00 开始，避免因脚本执行时刻浮动（比如某天 2:03 执行）导致延迟一天：/usr/bin/find /backup -daystart -mtime +7 -print - 调试阶段禁用
-delete，先用-print或-ls确认列出的确实是目标文件 - 限定作用范围：
-maxdepth 1防止递归进子目录误删；-type f明确只处理文件，避免rm意外删掉目录
日志和锁机制不是可选项，是必选项
没有日志，脚本失败你看不到；没有锁，多个定时任务同时跑可能删掉正在写的日志或清空一半的缓存。
例如两个 clean.sh 并发执行，都查到 /var/log/app.log 符合条件，一个刚 truncate 完，另一个又来 rm，或者都去 find ... -delete 同一批文件，结果不可控。
- 每行 crontab 必须重定向输出：
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; - 对关键操作（如清空大日志）加判断：
if [ -f /var/log/nohup.out ]; then cat /dev/null > /var/log/nohup.out; fi，避免cat /dev/null > missing.log创建空文件
最易被忽略的点是：-mtime 的时间基准不是“日历天”，而是“距今小时数”；sudo crontab -e 和普通 crontab -e 是完全隔离的两个 crontab；以及 cron 环境里 date 不一定支持 -d 选项——这些细节不验证，脚本大概率在某个凌晨两点彻底失联。
