不能在crontab里直接写rm命令，因为普通用户无权限删系统目录、cron默认path极窄导致命令找不到、错误未重定向而静默失败、缺乏锁机制引发并发误删，且文件名日期判断不可靠；必须用root权限封装脚本，显式声明解释器和绝对路径，配合-daystart与-mtime精准判断，加锁+日志+-print测试确保安全。
直接用 crontab 写 rm 命令清理垃圾，90% 的情况会静默失败或误删——权限、路径、环境、时间判断全都不对。必须封装脚本，用 root 权限调度，加锁+日志+绝对路径+-mtime 判断。
为什么不能在 crontab 里直接写 rm 命令
常见错误是往普通用户的 crontab -e 里加一行：0 2 * * * rm -rf /tmp/*。它看似每天跑，实则几乎从不生效：
- 普通用户没权限删
/tmp下其他用户创建的文件（Permission denied被 cron 丢弃，你根本看不到） -
rm在 cron 环境下找不到，因为默认$PATH只有/usr/bin:/bin，而有些系统把rm放在/bin/rm - 没重定向输出，错误全消失，你以为任务成功了
- 没加锁，如果前一次清理卡住，下次又触发，可能并发删一半正在写的缓存
必须用 sudo crontab -e 编辑 root 任务
清理 /tmp、/var/log、/var/cache 这类目录，脚本必须以 root 身份运行。编辑方式只有一种正确写法：
- 执行
sudo crontab -e，不是crontab -e - 不要在 crontab 行里写
sudo rm：cron 下sudo不会弹密码框，直接卡死或退出码 1 - 系统级任务别塞进用户 crontab；也不要用
/etc/crontab手动改（易被包管理器覆盖），统一走sudo crontab -e
脚本里必须显式声明解释器和绝对路径
哪怕你本地 bash 能直接跑，cron 默认用 /bin/sh 执行，且不加载 profile。脚本开头必须写：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
#!/bin/bash
然后 crontab 中调用时也得显式指定解释器：
- 写成
0 2 * * * /bin/bash /usr/local/bin/clean-junk.sh >> /var/log/clean.log 2>&1 - 所有命令用绝对路径：
/usr/bin/find、/bin/rm、/usr/bin/date，别信which find的结果 - 测试前先模拟 cron 环境：
env -i /bin/bash --noprofile --norc /usr/local/bin/clean-junk.sh，能立刻暴露路径/变量问题
用 -mtime +N 判断，别解析文件名日期
靠 backup_20240501.tar.gz 这种名字判断过期，极不可靠：
- 文件被
touch修改过时间戳，-mtime就失效了 - 命名不规范（比如多一个下划线、少一位数），正则就漏掉
- 时区错位导致“明明该删却没删”或“刚写完就被删”
正确做法是基于最后修改时间（即实际写入完成时间）：
-
/usr/bin/find /backup -type f -name "*.tar.gz" -daystart -mtime +7 -print：先-print确认列表，没问题再换-delete -
-daystart让计算从当日 00:00 开始，避免因任务执行时间浮动（比如凌晨 2:03 跑）导致延迟一天 - 加
-maxdepth 1防止递归进子目录误删；加-type f明确只处理文件
最容易被忽略的是锁文件和日志重定向——没锁，两个清理任务撞上可能删掉正在生成的备份；没重定向，find: cannot open ... Permission denied 这类关键错误你永远看不到。
