小服务器定时任务别乱写：crontab 里的三个坑

备份、清理日志、健康检查……小服务器上很多「每天自动做」的事都靠 cron。但 crontab 看着简单，写错了常常是静悄悄地失败——任务没跑，你也不知道。最常见的三个坑，写之前先避开。

第一个坑：环境变量不一样

cron 跑任务时的环境和你登录终端完全不同：PATH 只有最基本的几项，当前目录也不是你的家目录。所以「终端里能跑，cron 里就失败」的头号原因就是命令找不到。两个习惯能省很多事：

- 命令写绝对路径，比如 /usr/bin/python3 而不是 python3；
- 脚本开头先 cd /到/你的/工作目录，再做相对路径的事；
- 需要的环境变量在脚本里自己 export，不要指望登录时的 profile。

第二个坑：输出没地方去

cron 任务的输出默认会发邮件给系统用户，而小服务器上这个邮箱基本没人看。更糟的是任务报错了你也看不到。做法是把输出写进日志文件：

0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

>> 追加标准输出，2>&1 把错误输出也并进去。每天早上看一眼日志文件有没有新增的报错行，比等出事再查强得多。

第三个坑：时间写错了还不知道

0 3 * * * 是每天凌晨 3 点整，但 * 3 * * * 是 3 点那一小时的每分钟都跑一次——一字之差，任务量差 60 倍。还有一个常见错误：周日到底是 0 还是 7（两者都代表周日，但别混用），以及月份和星期是「或」关系不是「且」关系。

写完先验证：crontab -l 看一眼实际生效的内容；想立刻测试，临时把时间改成下一分钟跑一次，确认日志里有输出再改回正常时间。crontab 的改动立即生效，不用重启任何服务。

一个清单

备份脚本这类关键任务，写完按这四点自查：绝对路径、输出落日志、时间表达式逐项核对、立刻试跑一次看日志。定时任务本身就是为了省心，别让它变成半夜悄悄失败的隐患。