## 调度层的原因
第一，crond 服务没跑，systemctl status crond 一眼确认，装完系统被精简掉的情况真实存在。第二，时间字段写错，五个字段的顺序与取值范围反复核对，周字段 0 与 7 的兼容问题另算一类。第三，任务被写进了错误的文件，用户级任务用 crontab -e 编辑当前用户的，系统级在 /etc/cron.d 放文件，两边搞混互相找不到。第四，任务确实跑了但瞬间失败，系统 cron 日志里只有调度记录，没有任务输出，误以为没跑。第五，服务器时区或时间不对，任务在错误的钟点执行，看日志对不上时间点。此外还有夏令时与闰秒这类时间边界的罕见坑，国内业务基本无感，知道有这回事即可。
## 环境层的原因
第六，环境变量差异，cron 环境的 PATH 极简，脚本里的命令找不到，对策是全用绝对路径或在脚本头部自行声明变量。第七，百分号没转义，date 命令的格式串被 crontab 拆解，任务行为怪异，改成独立脚本调用最省心。第八，执行账号没有权限，目录不可读、文件不可执行、目标路径不可写，用任务同款账号手动跑一遍复现。第七条还有个变体：脚本解释器路径写错，比如系统里装的是 python3 而脚本头写了别的名字，命令本身就找不到解释器。
## 脚本层的原因
第九，上一轮还没跑完下一轮又启动，长任务叠加并发，资源互相打架还可能出现数据错乱，用 flock 加锁文件防重入，例：
bash flock -n /tmp/myjob.lock /opt/scripts/myjob.sh
-n 拿不到锁直接退出，天然跳过重叠轮次。第十，脚本依赖的前置条件未满足：数据库没起、远端主机不通、磁盘满，任务本身没毛病却次次失败。给脚本加上明确的失败输出与退出码，日志里留下证据。
## 排查心法
固定顺序三步走：先看 cron 日志确认调度了没有，再看任务日志看执行到哪一步，最后模拟 cron 环境手动复现。顺云云服务器上配好控制台的监控告警，任务该有的产物（备份文件、报表）缺失时人工核查，比事后追查可靠。再给每个关键任务配一个伴生的产物检查：备份任务检查文件新鲜度，报表任务检查行数，产物在就等于任务成功，比解析任务日志更直接。