脚本在终端里手动跑得好好的，放进 crontab 却一声不吭，这是定时任务最经典的翻车姿势。先说结论：cron 没跑脚本的概率很低，八成是任务被触发了但脚本自己挂了，而且挂的原因高度集中在 PATH 精简、权限不对、输出去向丢失这三类。按下面五项查，基本一遍过。
一查：cron 服务本身在不在跑
先排除最蠢的情况。Debian/Ubuntu 的服务名叫 cron，CentOS/RHEL 叫 crond：
# Debian/Ubuntu
systemctl status cron
# CentOS/RHEL
systemctl status crond容器和精简镜像里经常压根没装 cron，apt install cron 补上再 systemctl enable --now cron。
二查：任务到底有没有被触发
这一步能把问题一刀切两半。看系统日志里有没有 CMD 记录：
# Debian/Ubuntu
grep CRON /var/log/syslog | tail -30
# CentOS/RHEL
tail -30 /var/log/cron看到 CRON[12345]: (user) CMD (/path/backup.sh) 说明 cron 确实拉起了任务，问题在脚本本身；一条 CMD 都没有，则是任务没被识别。检查 crontab -l 是不是你预期的那份（root 的和普通用户的是两个文件），再看五个时间字段有没有写错。
→
→
→
→
三查：PATH 和环境变量
cron 拉起任务时用的是 /bin/sh，PATH 只有 /usr/bin:/bin，你的 ~/.bashrc 一概不加载。所以 python3、node、wp 这些命令直接写进去很可能 command not found。两个修法，推荐都做：
# crontab 顶部声明环境，作用整个文件
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# 命令本身也写绝对路径
0 3 * * * /usr/bin/python3 /opt/backup/run.py >> /var/log/backup.log 2>&1四查：脚本权限和结尾换行
脚本必须有执行权限：
ls -l /opt/backup/run.sh # 确认有 x
chmod +x /opt/backup/run.sh两个细节常被忽略：一是 crontab 文件最后一行必须换行，否则整条可能被忽略；二是命令里的 % 要转义成 \%，否则 date +%F 这类写法会把命令截断。
五查：输出去哪了
cron 默认丢弃脚本所有输出，脚本挂了你也看不见。给任务加上日志重定向，下次直接看文件：
# 标准输出和错误都进同一个日志
0 3 * * * /opt/backup/run.sh >> /var/log/backup.log 2>&1
# 然后
tail -f /var/log/backup.log| 环境 | PATH | 加载的配置 |
|---|---|---|
| 登录 shell（手动跑） | 含 /usr/local/bin、~/bin 等 | .bashrc / .profile |
| cron（开机跑） | 只有 /usr/bin:/bin | 什么都不加载 |
踩坑实录
接过一个数据同步任务，每天凌晨 3 点没动静，日志里连 CMD 都看不到。查了半天发现 crontab 装在 root 名下，而脚本里要连生产库，用的还是部署账号的凭据文件，cron 以 root 身份跑，读不到 /home/deploy/.pgpass，连库直接失败。改成部署账号的 crontab 并给脚本加 2>&1 重定向后，问题一次解决。教训：先确认任务在谁名下，再谈别的。
常见问题
Q：加了日志重定向还是空的，怎么办？
先确认 CMD 有没有触发（第二查）。触发了但日志空，大概率是 % 转义或脚本在 cron 环境下静默退出，把脚本第一行换成 #!/bin/bash -x 再跑一次，能打出执行轨迹。
Q：crontab -e 和自己写的文件有什么区别？
crontab -e 会自动处理换行和格式校验；直接 crontab file.txt 导入则没有这层保护，最后一行没换行、语法错都不会提醒，出了事很难查。
Q：任务间隔只有几秒的，用 cron 行吗？
不行，cron 最小粒度是分钟，秒级任务用 systemd timer 或专门工具。另外注意 cron 不会补跑错过的任务，服务器关机期间的任务就丢了。
定时任务这类排查还遇到过别的怪问题的话，欢迎到 fenij.com 留言，一起把坑填平。
