crontab 定时任务的写法与常见踩坑

crontab 的语法十分钟就能学会，真正让人头疼的是环境变量那几个坑。先把写法过一遍，再讲怎么避坑。 五段表达式回顾 依次是分、时、日、月、周，取值 0-59、0-23、1-31、1-12、0-7（0 和 7 都代表周日）。几个例子： 30 2 * * * /home/deploy/backup.sh —— 每天凌晨两点半 */10 * * * * /usr/local/bin/sync.sh —— 每十分钟一次 0 4 * * 1 /usr/bin/apt update —— 每周一凌晨四点 编辑当前用户的任务用 crontab -e，查看用 crontab -l。任务属于哪个用户，就以谁的权限和环境来执行。开机就要跑一次的任务，字段位置写 @reboot，不必挂在 rc.local 里。表达式还有个著名的歧义：日和周同时限定时是"或"的关系，不是"且"，排期时容易踩。 环境变量的坑 cron 的 PATH 只有一小段（通常 /usr/bin:/bin），你自己装到 /usr/local/bin 的程序它找不到。两个解法：命令一律写绝对路径，或在 crontab 顶部加一行 PATH=/usr/local/bin:/usr/bin:/bin。同理，脚本依赖的环境变量别指望从登录 shell 继承，要写进脚本自身。时区也留意一下：crontab 按系统时区调度，timedatectl 改过时区的机器，任务时间跟着挪。 另一个冷门坑：命令里的 % 号在 crontab 中表示换行，date +\%Y\%m\%d 必须转义，否则任务表现得很诡异。 系统级任务的另一个去处 /etc/cron.d/ 目录接受独立配置文件，格式比 crontab 多一个用户字段：30 2 * * * deploy /home/deploy/backup.sh。随部署包分发的定时任务常放这里，版本化管理更方便。任务密度高、彼此有依赖的，还可以看一眼 systemd timer：同样的定时能力，日志、超时与依赖控制都更强，journalctl -u 定时器名直接查记录，新任务值得优先考虑。 用重定向留证据 不带重定向的任务，报错只会进邮件，而多数机器根本没配邮件，坏了也没人知道。标准写法： 30 2 * * * /home/deploy/backup.sh >> /var/log/backup.log 2>&1 任务没按时跑，按固定三步定位：crontab -l 确认任务在；grep CRON /var/log/syslog 或 journalctl -u crond 确认被调度；再看重定向日志确认脚本自身的退出码。三步走完，问题一定现形。