定时任务没跑，别先怀疑代码

有一次，一个定时任务手动跑好好的，放到 cron 里就不执行。第一反应是代码在定时环境下出了问题，查了半天，最后发现是环境变量。手动执行时 shell 里有 PATH 和一堆自定义变量，cron 启动的环境干净得多，脚本里写了个没写全路径的命令，手动能找到，cron 里找不到，就静默失败了。

这件事之后，排查定时任务养成了一个固定顺序。先看 cron 服务本身在不在跑，系统重启后有没有起来，任务列表里有没有这条，时间表达式写没写错。分钟和小时写反、星期和日期混用，这类低级错误比代码 bug 常见得多，crontab 的时间字段从左到右是分时日月周，写的时候对照着数一遍，比事后查日志快。

服务和时间都没问题，再看执行环境。脚本第一行有没有写解释器路径，脚本本身有没有可执行权限，里面用到的命令是不是全路径，相对路径在 cron 里指向的目录和手动执行时不一样，输出文件也一样。稳妥的做法是脚本开头把常用路径写全，输出统一重定向到一个日志文件，标准输出和错误输出都别丢。任务没跑的时候，先看这个日志，比猜快得多。

还有一处容易漏，就是时区。服务器时区和人想的时区不一样，任务按服务器时间跑，表面看就是提前或者推迟了几个小时。改时区或者写任务时间之前，先用 date 确认服务器当前时间，别按自己的手表算。

日志里如果什么都没有，说明任务根本没被触发，往 cron 服务和时间表达式上查。日志里有报错，顺着报错走，多数是路径问题、权限问题，或者环境变量没配好。代码本身反而是最后才怀疑的对象，手动能跑、定时跑不了，差别基本都在环境上，不在逻辑上。

另外一个小习惯：新任务上线先把时间设成最近的几分钟，跑通一次再改回正式时间。等到第二天早上才发现一夜都没跑，补起来比验证一次麻烦得多。