定时任务到了时间却没跑？先查这三处

crontab 写好了，到了时间却一点动静没有，但手动跑脚本又是正常的。这种情况多半不是 cron 坏了，而是下面三处没对上，按顺序查一遍基本能定位。

第一，查任务是不是真的加载了。先看 cron 服务在不在跑：Debian/Ubuntu 用 systemctl status cron，CentOS/RHEL 用 systemctl status crond。再用 crontab -l 确认任务确实写进了当前用户的 crontab，注意别写进了 root 的任务却用普通用户去查，或者反过来。改完 crontab 一般不用重启服务，cron 会自动重载，但前提是写对了地方。

第二，查环境变量和路径。这是最多人踩的坑：cron 的运行环境非常精简，PATH 通常只有 /usr/bin:/bin，~/.bashrc 里的别名、自定义变量、conda/nvm 之类的路径一概没有。脚本里写了相对路径、裸命令名（比如 python、node、aws），在终端里能跑，在 cron 里就找不到。办法有两个：脚本里一律写绝对路径；或者在脚本开头 source 一下需要的环境。验证办法很直接：加一条 * * * * * env > /tmp/cron-env.txt，跑一次就知道 cron 眼里的环境到底长什么样，跟终端对比一下就清楚了。

第三，查输出和日志。cron 默认把任务输出发邮件，本机没配邮件的话输出就直接丢了，人就以为“没跑”。正确做法是命令后面加上重定向，比如 >> /var/log/mytask.log 2>&1，把标准输出和错误都落到文件里。再结合系统日志看：journalctl -u cron 或者 /var/log/cron，能看到任务到底有没有被触发。动手顺序应该是：先手动跑一遍确认脚本本身没问题，再去怀疑 cron。

总结一下：定时任务没跑，先确认任务加载了、再对环境和路径、最后看日志和输出。多数情况查到第二步就破案了。