1. 从一次半夜的报警说起：cron明明配置了，任务就是不跑

大概凌晨两点多，手机连着震了好几下。监控群里说线上某个数据同步任务已经两个小时没出数了。我第一反应就是去看那台机器上的crontab，结果配置好好的，命令也没写错，手动执行脚本也一切正常。但任务它就是没跑。

这类"cron不执行"的问题，干运维和后台开发的基本都遇到过。大多数人第一件事是检查crontab配置有没有语法错误，然后看crond服务是不是挂了，最后再看看日志。但说实话，真正线上出现过的人都知道，大多数时候crond是活着的，配置看着也没问题，脚本单跑还正常，可定时任务就是在某个时间点毫无动静。

这篇文章我就把自己这几年在cron问题上踩过的坑、排查过的案例、总结出来的方法论完整写一遍。适合谁看呢？一类是刚接手服务器没多久的初级运维，另一类是写脚本做数据同步、报表生成、缓存清理的后端开发，还有一类是用了xxljob这类分布式调度平台但仍然需要依赖服务器cron做兜底的架构师。文章不会只讲"看日志"这种泛泛的东西，我会把整个排查链路拆成可执行的具体步骤，每一步都告诉你为什么要这么做，以及最常见的坑在哪里。

先说一个我自己的判断习惯：凡是cron定时任务不执行，先别怀疑crond挂了，先怀疑环境的差异。因为手动执行和cron执行，最大的区别不在于命令本身，而在于"谁"在执行它、在什么环境里执行它、在什么工作目录下执行它。搞清楚这三件事，一半以上的问题就已经解决了。

不过在我展开讲排查链路之前，有一个非常反直觉的事实我必须先抛出来：在绝大多数Linux发行版上，crond进程即使配置有误，也不会在系统日志里留下任何"任务执行失败"的记录。 更麻烦的是，很多发行版默认的cron实现甚至不会为普通任务保留独立日志。这意味着你如果一开始就把排查重心放在"看日志"上，大概率会白忙活半天。真正可靠的证据链，其实藏在另一个地方，后面我会专门写一节。

先搭一个整体的排查框架，后面每一节都围绕这个框架展开。整个排查思路可以分成六层：行为层、环境层、依赖层、实现层、触发层、平台层。行为层解决"任务到底跑没跑"的问题；环境层解决"为什么跑起来跟手动不一样"的问题；依赖层解决"为什么脚本里的命令、环境变量、网络不可用"的问题；实现层解决"为什么Java/C#这些语言写的任务特别容易出问题"的问题；触发层解决"为什么时间到了但没触发"的问题；平台层解决"为什么用了分布式调度平台还是会有漏执行"的问题。下面按照从浅入深、从单机到分布式的顺序，一条一条拆开讲。

2. crond的"日志隐身术"：日志和status文件修改时间才是硬证据

2.1 MAILTO/输出重定向：任务其实跑了，你看不见而已

先看一个最经典、也最容易误判的场景。你在crontab里写了这样一行：

code复制0 2 * * * /opt/scripts/sync_data.sh

凌晨两点到了，任务没产生任何输出日志，数据也没同步，于是你断言"cron没执行"。但你有没有想过——这行配置执行了，只是执行的结果在系统日志里根本看不到，脚本的输出又被cron吞掉了。

大多数Linux发行版，默认情况下cron执行任务时，如果任务产生了标准输出（stdout）或标准错误（stderr），并且没有做重定向，crond会把输出内容通过邮件发送给执行任务的那个用户（本地mail）。很多服务器上根本没装邮件服务，或者mail命令没人配置，这些输出就直接进了/var/mail或者/var/spool/mail，成了一堆没人看的垃圾文件。在某些最小化安装的系统上，甚至直接就丢了。

所以第一步的排查动作就两个：一是看系统日志里有没有那个时间点的crond相关记录（虽然大多数发行版默认没有，但看一眼成本很低，万一你的系统开启了就赚到了）；二是看这个用户有没有本地邮件，邮件内容往往就是任务执行时的报错输出：

bash复制ls -la /var/mail/
cat /var/mail/root

这里有一个很多人不知道的判断技巧：直接看cron状态文件或者日志文件的修改时间。例如在CentOS/RHEL系列的cronie实现里，系统日志通常在/var/log/cron；而Debian/Ubuntu的cron默认只记录到syslog，很多时候需要自己配置。更简单的做法是打开cron的日志审计：

bash复制systemctl status crond
grep CRON /var/log/cron

但如果你发现日志文件时间戳在那个时间点变了，哪怕里面没有你那条任务的记录，也说明crond进程确实"醒来"过、处理过某个队列。再配合一个更有说服力的证据——cron的status文件，例如/var/lib/systemd/cron或类似路径，它就记录了每个任务的最近执行状态，文件内容的修改时间本身就是任务有没有被调度的铁证。

2.2 最保险的三个月习惯：每条cron任务强制重定向输出

我自己处理过的线上cron问题里，有接近四成最后都指向了同一个习惯问题：写crontab的时候不重定向输出。这个习惯必须改。

正规写法是给每条可能产生输出的任务加上标准输出和标准错误的落盘：

bash复制0 2 * * * /opt/scripts/sync_data.sh >> /var/log/sync_data.log 2>&1

追加日志而不是覆盖日志，这一点必须注意。很多人图省事用单个>符号，结果第二次执行就把第一次的日志清了，真出问题时现场早就被破坏掉了。正确做法是统一追加到日志文件，日志轮转交给logrotate处理。

加了重定向之后，你就拥有了第一个"任务到底跑没跑"的一手证据。凌晨两点任务执行完，第二天早上第一件事就是看这个日志文件的最后修改时间。有一种情况很诡异：日志文件时间戳变了，但里面是空白的，或者只有几行不知所谓的输出。这种情况往往说明脚本开头就出了问题，比如某个source路径不存在导致脚本直接退出。日志文件时间变了，本身就是"cron执行了你的任务"的强证据，这时候责任就从cron转移到了脚本本身。

再补充一个很有用的自我检测小技巧。如果你不确定crond的执行环境到底长什么样，可以故意在crontab里加一条这样的任务，让它每个小时执行一次然后看输出：

code复制15 * * * * env > /var/log/cron_env.log 2>&1

env命令输出的就是cron环境下所有环境变量和PATH的完整内容。跑几次之后打开这个文件，你会看到和SSH登录终端完全不一样的PATH。这个文件能帮你快速定位一大堆"脚本手动跑没事、cron跑就失败"的问题。等排查完记得删掉这条任务，不然每小时覆盖一次日志文件，久了也麻烦。

2.3 从"日志/status"时间戳看出的冷门坑：时区与系统时钟漂移

看到这里你应该已经形成了一个习惯：先看日志有没有变化，再看输出文件有没有内容。但还有一类更隐蔽的问题，会让你连"日志时间戳变了"这个证据都产生误判——系统时钟漂移和时区错位。

服务器跑了半年一年，又没有配置NTP时间同步的话，系统时间可能偏差几分钟甚至十几分钟。你期望凌晨2点跑任务，实际机器时间才1点47分，任务自然没跑。反过来更坑的情况是宿主机是虚拟化的，系统时间被宿主机拖慢，cron提前触发了，但数据库备份的窗口还没到，数据文件不完整，第二天一看发现备份坏了。

排查时先用date命令确认系统时间和时区：

bash复制date -R
ntpstat
timedatectl

如果发现系统时间和真实时间差太多，先去修时间同步，再回头验证cron任务。这里有一个很容易被忽略的细节：服务器上如果跑了多套语言环境（Java、Python、Go各来一套），每套语言运行时的时间处理逻辑还不一样，cron任务触发的日志用的是系统时间，但Java的日志可能用的是JVM默认时区，两边一对比就对不上，排查方向瞬间就歪了。

我处理过的一个真实案例是：某台服务器上cron任务一直在跑，但业务方坚称"任务没执行"，原因是他们看到的日志消息时间晚了一个小时，跟业务报表里的时间对不上。最后排查发现，cron任务本身完全正常，只是应用内设置的时区是UTC，而业务方按北京时间核对，白白浪费了一下午。所以现在我看到"cron不执行"的问题，第一件事永远先问一句：你确认看的那台服务器的时间和时区是对的么？这个问题的优先级甚至高于去翻crontab。

3. 为什么手动执行没问题，cron一跑就失败：环境差异三层拆解

3.1 第一层：PATH变了，命令找不到了

这是所有cron环境差异里最常见的坑，没有之一。

你SSH登录上去，用的是bash或zsh，登录shell会读取/etc/profile、~/.bashrc、~/.bash_profile等一系列文件，把PATH设置成包含/usr/local/bin、/usr/local/sbin、/opt/java/bin等一堆路径的完整值。在这个环境里你执行sh脚本，里头的java、python3、docker、kubectl命令都能找到。

但crond执行任务时，用的基本上是/bin/sh（很多发行版实际是dash或bash的POSIX模式），它不读取你那套登录shell的初始化文件，PATH默认经常只有/usr/bin:/bin。如果你脚本里写了某个不在这个PATH里的命令，比如/usr/local/bin的某个工具，直接按命令名调用，cron环境里就找不到。

一个很典型的报错是：

code复制sync_data.sh: line 3: mysqldump: command not found

但这句话你不重定向输出的话，它只会出现在系统邮件的某个角落，甚至直接被丢弃，你根本看不到。

解决的办法有几种。最简单的就是把脚本里用到的命令都改成绝对路径：

bash复制/usr/bin/mysqldump -uroot -p*** > /tmp/backup.sql

但这会带来一个问题：脚本一旦换机器部署，路径可能就不一样了，可维护性变差。更推荐的做法是在脚本开头主动source环境变量文件：

bash复制#!/bin/bash
source /etc/profile
source ~/.bash_profile

这两个文件的路径和内容在不同系统上差异很大，Debian系和RedHat系截然不同。稳妥做法是脚本开头先把关键路径显式拼进PATH，而不是依赖系统初始化文件：

bash复制export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

这个写法代价小、可控性强，脚本在任何机器上都不会因为PATH问题出错。我自己写脚本的习惯是：凡是要用到的第三方命令，一律先whereis确认路径，然后在脚本里用变量存绝对路径。虽然看起来啰嗦，但脚本的可移植性和可排查性立刻上了一个台阶。

3.2 第二层：环境变量丢了，脚本跑了一半"莫名"失败

PATH只是环境变量的冰山一角。很多脚本依赖的环境变量比PATH更隐蔽。

最典型的例子是JAVA_HOME。你的Java应用知道去哪找JDK，通常是因为/etc/profile里定义了JAVA_HOME并export了。但crond执行任务时既不读/etc/profile也不读~/.bashrc，JAVA_HOME对cron环境来说就是未定义。结果就是Java进程启动时报"Unable to locate a Java Runtime"，或者某些部署在tomcat里的应用根本起不来。

数据库连接字符串、API密钥、内网代理等也经常通过环境变量注入。你手动测试时，这些变量来自当前shell的export；但是cron环境干干净净，什么都没有，脚本跑到一半连数据库失败，日志打的还是中文字符乱码（因为LANG没了），整个场景简直一地鸡毛。

排查技巧是：在脚本比较靠前的位置加一段调试输出，把关键环境变量打出来：

bash复制echo "PATH=$PATH" >> /tmp/debug.log
echo "JAVA_HOME=$JAVA_HOME" >> /tmp/debug.log
echo "LANG=$LANG" >> /tmp/debug.log

跑一次之后去看/tmp/debug.log，立刻能看出cron环境和手动环境的差异到底在哪里。如果环境变量特别多，也可以直接env > /tmp/cron_env.log，然后和手动环境的env输出做一个diff。这一步做完，脚本为什么不工作的原因基本就浮出水面了。

3.3 第三层：工作目录不对，相对路径全废了

这一层又是一个超级常见的坑，而且它特别坑"新手"。

你在SSH终端里进入/opt/myapp目录，然后执行./run.sh，一切正常。这个命令被写进crontab之后，你以为它还是从/opt/myapp目录执行，但实际上crond执行任务时默认的工作目录是执行任务用户的家目录，或者是/，总之不是你那个应用目录。脚本里凡是用相对路径的地方——比如./logs/app.log、conf/config.yml、data/dump.sql——全部失效。

我见过一个特别惨的案例：某团队的备份脚本里写了一个rm -rf ./backup，他们手动测试时在/opt/project目录下，脚本把backup目录清掉了，一切正常；上线cron之后，系统从根目录执行了这个脚本，rm -rf ./backup直接变成rm -rf /backup，如果/backup不存在还好，万一某台机器上确实存在/backup目录，那一天的工作成果就全没了。虽然rm -rf相对路径到/这个级别的风险其实是有限的，但类似误删除的教训在运维圈确实发生过。

解决思路只有一个：脚本绝对不要依赖当前工作目录。在脚本开头用cd命令显式切换到固定目录，或者所有路径全部用绝对路径引用。推荐做法是：

bash复制#!/bin/bash
cd "$(dirname "$0")" || exit 1

这行代码的意思是：无论cron从哪个目录执行这个脚本，都会先切换到脚本自身所在的目录，然后再执行后续逻辑。这一行几乎可以解决所有因为工作目录不对导致的"找不到配置文件""找不到依赖文件"问题。

另一个跟工作目录相关的细节是：cron任务里如果调用了别的脚本，这个脚本内部又依赖相对路径，那么你在外层切换目录是不够的，内层脚本同样要做类似处理。排查时养成一个习惯：进入脚本目录，用sh -x script.sh跑一遍观察每一步实际执行了什么，再看cron执行时用同样的方式是否一致。

4. 从"改完crontab不生效"到"重启crond才能加载配置"：那些配置加载机制上的认知误区

4.1 奇怪的印象：改了crontab要不要重启crond服务

这个问题在我接触过的团队里，几乎每三个人就有一个答案不同。有人说要重启，有人说不重启，还有人说自己那边改了配置等了半天才生效。

先把结论说清楚：绝大多数现代Linux发行版（使用cronie或Vixie-cron），你通过crontab -e修改配置后，是不需要重启crond服务的。 crond每分钟会重新读取一次crontab文件，新的配置最迟一分钟以内就会生效。但是有例外情况：如果你直接把/etc/crontab文件手动改坏了，或者在某些特殊实现里修改了配置但语法不合法，crond可能在加载时直接报错，导致整批任务都不工作了。

这个"不改就直接改文件"的做法其实踩坑概率极高。很多人图省事直接用vim编辑/etc/crontab，或者用echo追加一行到/etc/crontab，完了也不做语法检查，crond加载时遇到语法错误，很可能把整个解析跳过，于是你所有任务都不执行了。

正确的"改配置"姿势：

bash复制crontab -e   # 编辑当前用户的crontab，会自动做基础语法检查
crontab -l   # 查看当前用户的crontab

如果你确实需要直接操作/etc/crontab文件，改完之后可以用crontab -u root /etc/crontab来重新加载，或者用/etc/init.d/cron reload（不同系统命令不同，CentOS上是/etc/init.d/crond reload）。这里要特别注意，不同发行版对"校验"的严格程度不同，Ubuntu的cron对语法极其敏感，某个字段多写了一个星号都会直接被拒，而且拒绝后旧配置可能也不生效。所以改完配置后，立刻查一下crontab -l确认当前实际生效的内容，这一步成本极低，价值极高。

4.2 字段顺序、注释符号、括号陷阱：crontab语法的隐形雷区

crontab语法看着简单，五个时间字段加一个命令，但真正出起问题来千奇百怪。

最容易犯的错误就是字段顺序。crontab的正确顺序是：分、时、日、月、周，共5个时间字段。但很多从业务系统转过来的人第一次接触，会天然地按"时分秒日月年"去理解，结果把分钟和小时写反。比如你本来想早上8点跑一次同步任务，写成：

bash复制* 8 * * * /opt/scripts/sync.sh

这行的含义是"8点这一小时内的每一分钟都跑一次"，也就是8点整到8点59分之间每分钟执行一次，总共执行60次。真正正确的写法是：

bash复制0 8 * * * /opt/scripts/sync.sh

这种错误在线上出现过很多次，而且特别隐蔽，因为看着不像语法错误，任务确实"每天8点都在跑"，只是它跑得太频繁了。

另一个雷区是注释和转义。crontab里以#开头的行是注释，这没问题。但是很多人在cron命令里写包含%的表达式，比如date +%Y%m%d，这里的%在cron语法里是有特殊含义的，它会作为换行符处理或者被忽略，导致命令行为异常。cron环境下所有%字符都必须转义成%才能正常工作。这个坑在写日志归档脚本时特别容易踩到，比如你想给日志文件打上日期后缀：

bash复制0 0 * * * /usr/bin/find /var/log -name "*.log" -mtime +7 -exec rm -f {} \;

那行里的花括号{}本来就是find的占位符，在crontab里一般没问题，但遇到某些特殊字符时，建议统一用单引号包裹起来，避免被cron环境二次解释。

再一个值得注意的点是周字段的语义差异。某些cron实现里，周日和周一都代表同一天，但不同实现的做法还不是完全一致。为了避免困惑，建议在crontab里统一用数字0-7（0和7都代表周日）而不要用缩写。最重要的是，如果某个任务同时指定了"日字段"和"周字段"，两个条件其实是OR的关系，不是AND。这是cron语法里最反直觉的一点，无数人在配置"每月1号和每周一执行"时，因为理解成AND而写错配置。

4.3 分钟精度与"秒"的缺失：为什么"半小时执行一次"和"每秒执行"都那么别扭

cron设计的核心精度是分钟级，没有秒级。所以当你看到某些文章教你用cron实现"每秒执行"的方案，心里要有数，那都是在用拼参数的方式绕版本限制，并不是cron本身的能力，往往还伴随着风险。

比如你要实现每30秒执行一次某个轻量任务，常见的方案是启动两个cron任务，错开30秒：

bash复制* * * * * /opt/scripts/onetime.sh
* * * * * sleep 30 && /opt/scripts/onetime.sh

这种写法能工作，但有一个很严重的副作用：第一个cron任务和第二个cron任务的执行时刻不是精确对齐的，如果上一条任务还没执行完，下一条任务又会启动一个新进程，可能导致并发冲突。cron没有内置任务锁机制，这是设计上就存在的边界，不是bug。业务逻辑里应该自己保证幂等：加锁文件、用flock、或者实现单例保护。

另外，关于"半小时执行一次"，很多人直觉以为写0,30 * * * 就好，反过来也有人以为是/30，两者其实基本等价，但*/30的写法在不同cron实现里有时会有细微差异（比如是否支持除法和余数），为了稳妥我一般推荐把关键时间点明确列出来，比如每分钟、每两分钟、每半小时，清晰列出来比模糊的步长语法更容易排查问题。

5. Java/Spring生态里的cron定时任务：注解、线程池和分步执行

如果你不是做Java后台的，这一节的某些部分可以略读，但Java生态踩过的几个坑对其他语言（比如C#、Python）一样有参考价值。

5.1 @Scheduled cron表达式：两个执行器的认知鸿沟

Spring Boot里使用cron定时任务的方式很简单，在方法上加上注解就行：

java复制@Scheduled(cron = "0 0 2 * * ?")
public void syncData() {
    // ...
}

很多从Linux crontab走过来的人第一次看到Spring的cron表达式会愣一下：为什么是6位？因为Spring的cron表达式包含了秒字段。格式是：秒 分 时 日 月 周，6个字段。而Linux crontab只有5个字段（分 时 日 月 周），没有秒。这两者的字段顺序不一样，而且Spring的周字段范围是0-7（0和7都是周日），还可以用SUN这种英文缩写；日字段和周字段的语义也和Linux crontab不同（Spring默认也是OR关系，但配置的方式更灵活）。

这个差异直接导致了一个非常常见的排查事故：运维把一段Linux的crontab表达式"翻译"成Spring的@Scheduled表达式，由于没有秒字段，整个时间全都错位了。举一个真实案例：某团队把"每天凌晨2点执行"的Linux表达式0 2 * * *，直接抄进Spring的@Scheduled里，结果那行被解析为"每秒执行一次，且只在第2秒的那一瞬间执行一下"——几乎等于每秒都在跑，数据库直接被压垮了。排查半天发现，是因为秒字段被忽略之后表达式含义全变了。

Spring的@Scheduled还有两个典型的坑。第一个是默认单线程模型。Spring的定时任务默认情况下使用的是单线程的ScheduledExecutorService，也就是说：如果有多个@Scheduled任务，它们排队执行，一个任务卡住了（比如访问外部API超时），后面所有的定时任务都会跟着卡住。表现为"任务A每天正常跑，任务B每一小时跑一次但某天下午突然不跑了"，其实B一直在等A释放线程。解决办法是在配置类里自定义线程池，把TaskScheduler的线程数调大：

java复制@Configuration
public class SchedulerConfig {
    @Bean
    public TaskScheduler taskScheduler() {
        ThreadPoolTaskScheduler scheduler = new ThreadPoolTaskScheduler();
        scheduler.setPoolSize(10);
        scheduler.setThreadNamePrefix("scheduled-task-");
        return scheduler;
    }
}

第二个坑是事务、代理和自调用问题。@Scheduled方法如果在同一个类里被另一个方法调用，注解可能不会生效，这也是Spring AOP自动代理机制的一个经典陷阱。不过这个坑在Spring Boot新版本里已经不太常见了，因为通过构造器注入会自动使用CGLIB，但对老项目来说依然是排查重点。

5.2 分布式下的@Scheduled：多实例重复执行与资源竞争

在单机上用@Scheduled完全没问题，但一旦你把应用部署成多个实例，比如两台机器跑同一个服务，前边K8s里有3个Pod，那么这段@Scheduled的定时任务的逻辑会在每个实例上都执行一次。如果你的任务做的是"清空临时表再重建"这种非幂等操作，结果就会变成：两个实例同时清理同一批数据，一个清了另外一半，数据库直接产生异常。

这是Spring原生@Scheduled在分布式场景下的天然短板，它本身不包含分布式锁或任务分发机制。常见的解法有三类：搞个分布式锁（Redis锁、数据库锁）、用xxl-job这类调度平台、或者自己实现一个简单的选主选举。其中最经济的做法是用Redis做分布式锁，在任务入口处加锁，加锁成功的实例执行，失败的跳过。但要注意锁的过期时间：任务执行时间不能超过锁的自动释放时间，否则另一个实例就会在锁过期后一把抢走任务，导致重复执行。我见过一个任务执行2小时，锁过期时间设置了1分钟，结果锁刚释放，两个实例同时拿锁成功，数据又重复处理了一遍。

所以在引入分布式调度平台之前，要充分评估你的任务到底是不是幂等的。如果任务本身是幂等的（比如"把文件从A目录复制到B目录"这种具备覆盖特性的），不上锁问题也不大；但涉及数据库非幂等更新、外部接口调用、扣减库存这类操作，就必须认真处理并发问题。

5.3 xxl-job等调度平台的正确使用方法：跟cron之间的边界划分

搜索热词里出现了"xxljob定时任务api""springcloud+架构中关于分布式定时任务的解决方案"这些词，说明很多团队在做微服务、分布式架构时，都会面临"单机cron不够用，分布式调度要用哪个"的选型问题。

xxl-job这类平台的核心价值在于：统一的调度中心、可视化的任务配置、失败重试、告警通知、日志追踪，以及分片广播等高级策略。它解决的是分布式环境下的任务编排和可靠性问题，不是单纯"把cron搬到网页上"。但这也出现了一个典型的混淆：很多团队把原本能用cron稳定跑的任务，全部迁到调度平台上，反而导致任务不执行时定位都麻烦——调度平台本身挂了、网络不通、任务超时、分片参数不对，每个环节都可能出问题，排查的面更大了。

我这里给一个个人经验总结的划分建议：

• 单机、单实例、轻量、低频的任务（比如本机日志清理、本地临时文件清理、简单的数据导出），优先用cron解决，简单直接，不引入额外依赖。
• 多个实例都能执行的非幂等任务、需要精确控制只跑一次的任务，建议用分布式调度平台或加分布式锁。
• 任务逻辑较重、耗时较长、需要分片处理、需要失败重试和告警的，必须用调度平台。
• 需要动态调整执行周期、上线后频繁改时间、按业务维度配置不同执行频率的，调度平台的配置中心和API会远比修改crontab方便。

用xxl-job时几个常见的坑也值得提醒一下：调度日志和任务执行日志要区分开；失败重试的默认次数和间隔建议根据业务评估，否则一个假失败任务重试10次把下游打爆；分片广播模式下要确保每一片处理的"数据分片"确实是互斥的，这个逻辑写错会导致重复处理或者数据空洞。另外，xxl-job的Cron表达式同样遵循6位字段的标准（秒 分 时 日 月 周），这里和Spring的@Scheduled表达式的语义一致性比较好，但如果是从Linux抄过来的5位表达式，同样存在字段错位的风险。

6. 那些最容易被忽略的触发级真相：AM/PM、DST、夏令时和任务重叠

6.1 12小时制引发的"中午跑"和"半夜不跑"

如果你看到某个cron任务在"12:30"的时间点不该跑却跑了，或者反过来"0:30"没跑，第一反应往往不是cron问题，而是"是不是配置了12:30但理解成凌晨了"。

这在跨时区团队特别常见：有人在配置环境时用24小时制，在cron表达式里写了0 12 * * *，意思是"每天中午12点跑"，但业务方口口声声说"每天凌晨0点跑"。两边都没错，错的是一方按24小时制理解，另一方按12小时制表达。排查时记得时刻问一句：业务方说的时间到底按哪个时区、哪个制式。虽然看着很低级，但它真的坑过很多人。

6.2 夏令时切换和时区变更：任务突然少跑一次、多跑一次

如果你维护的服务器上跑了跨时区业务，并且所在地区实行夏令时（DST），那cron任务在切换日的表现会让你怀疑人生。

在春季切换"Spring Forward"的那一天，凌晨2点的时间会直接跳到3点，那一次cron任务……如果配置在2:30，它压根不会执行，因为那一刻时间不存在。在秋季"Fall Back"的那一天，2点会重复出现两次，那同一个cron任务可能执行两次，或者在某实现里只执行一次，取决于crond对时间重复段的处理策略。由于不同发行版实现不完全一致，这种"不执行"或"多执行"的现象在日志里一般都没有明显异常，因为它不是任务本身出错，而是时间本身出了问题。

在国内这个坑可能比较少遇到（中国现行历法没有夏令时），但如果你维护面向海外用户的系统，或者哪怕只是日志服务器用的某个时区策略影响到了业务时间戳，都要注意这个边界。最稳妥的做法是：要么所有cron任务统一用UTC时间，然后业务展示层再转本地时间；要么让运维明确记录哪些服务器开启了DST相关策略。国内不少公司的做法是即使服务器在海外，也统一设置成CST北京时区，除了业务特殊需求，时间处理会简单很多。

6.3 任务重叠：上一次还没跑完，下一次触发了

这一类坑在jedis/redis、MySQL备份、批量数据同步任务中特别常见。表现为：任务本身执行时间通常只需要20分钟，但某天数据量突然变大，跑了40分钟，而cron配置是每30分钟执行一次，于是上一次任务还没结束，下一次触发又来了。

两个任务同时运行，可能产生两大问题：一是数据库连接数被占满；二是两个实例同时处理同一批数据，导致数据重复、锁等待、数据错乱。cron本身没有"单例保护"机制，它不会因为你上一条任务还在跑就不触发新的实例。

解决方案无非是几类：

• 在脚本开头加锁文件判断（flock是两个比较方便的命令）：

bash复制exec 9>/var/lock/mytask.lock
flock -n 9 || exit 1

flock -n表示拿不到锁就直接退出，避免阻塞堆积。如果任务必须要排队而不是跳过一次，可以把-n去掉，让它阻塞到上一个执行完。

• 在任务里记录PID，启动时检查旧PID对应的进程是否存在，存在就退出。

• 对于Java/Spring应用，用分布式锁/调度平台里的阻塞策略来控制（xxl-job提供"单机串行""丢弃后续调度""阻塞处理"等策略，选型时根据业务容忍度来）。

判断是否存在任务重叠，最直接的手段是看日志文件里是否出现了两个线程ID同时处理数据，或者看数据库里是否有两条几乎同时产生的同批次记录。设置好日志并梳理清理策略之后，这个问题很容易从日志时间戳里看出来。

7. 从运维到开发的全链路排查清单：把"检查手段"变成"习惯动作"

说了这么多案例和方法，最后给一套可以直接照抄的排查checklist。你不用背下来，但遇到"cron不执行"的问题时，按这个顺序走一遍，90%的问题能在十分钟内定位。

第一件事：确认时间和时区。执行date -R，看系统时间和时区是否是预期值。再执行timedatectl确认NTP同步状态。如果系统时间和真实时间差几分钟，先修同步再继续排查。

第二件事：确认crond进程活着。执行systemctl status crond（CentOS系）或service cron status（Debian系）。进程死了直接重启，再观察下一个时间点是否执行。这里值得多说一句：有些容器环境里根本没有crond进程，你写的crontab之所以不生效，是因为容器里压根没启动cron服务。这是容器化环境里一个特别经典的"不执行"原因，排查时要额外注意。

第三件事：检查crontab配置本身。执行crontab -l，对照"分 时 日 月 周"字段顺序，确认没有写反。特别注意%符号有没有转义，多字段条件的AND/OR语义是否符合预期。

第四件事：看日志和输出文件。先看/var/log/cron（CentOS）或journalctl -u cron（Debian/Ubuntu）确认那个时间点crond有没有醒来并处理任务列表；再看你脚本重定向的日志文件最后修改时间是不是符合预期。注意区分"crond了任务"和"脚本执行成功"是两回事。

第五件事：手动模拟cron环境执行脚本。用env -i /bin/bash script.sh的方式在一个干净环境里跑一遍脚本，观察它是否真的能成功。如果能复现失败，说明就是环境变量、PATH或者工作目录的问题。如果env -i这种方式不好用，也可以使用crontab临时加一条env > /tmp/env.log任务对比环境。

第六件事：检查脚本依赖。确认脚本里有没有用到cron环境里不存在的命令、环境变量、网络路径或文件路径。脚本里加日志输出到固定文件，是成本最低的调试方式。

第七件事：如果是分布式环境，去排查调度中心（xxl-job等）的任务状态、执行日志、失败重试策略以及实例负载。排在最后的原因不是不重要，而是它涉及的面更广，应该先从单机层面排除掉cron本身的嫌疑，再去查平台侧。

第八件事：如果上面全查完了还找不到问题，就做一个"反向验证"——主动构造一个理论上必然会执行的测试任务，比如每分钟写一次时间戳到/tmp/test.log。如果这个测试任务能正常执行，说明crond本身工作正常，问题一定出在你的脚本或配置本身；如果测试任务也不能执行，那就要去审视crond的权限、配置文件和系统状态，而不是继续埋头折腾脚本了。

这套清单的价值在于：它把"从现象推断原因"变成了"按顺序排除嫌疑"，每一步都基于可观测的证据，而不是玄学。排查Cron问题最忌讳的就是凭感觉东改西改，改完等10分钟再回来看到底跑没跑——这是无数人耗时最长的原因。

8. 从一次误删事故到写脚本的好习惯：脚本健壮性比cron本身更值钱

最后聊几个我个人的实操体会，不算标准答案，但每一条都是在真实事故里换来的。

先说一个最让我印象深刻的教训。某次线上服务因为cron任务反复失败，日志里全是数据库连接超时的报错，最后排查发现不是数据库挂了，而是备份脚本在cron环境里拿到的工作目录不对，相对路径指向了一个磁盘空间很小的分区，日志文件把磁盘写满了，然后数据库连接也无法建立，整条链路一起崩。从表面看是"cron不执行"，实际是"脚本自身不健壮导致连锁反应"。如果当时脚本开头加了cd切换目录和磁盘空间检查，这起事故完全可以避免。

所以我现在写脚本有五个固定习惯，分享给各位参考：

第一，脚本开头统一做四件事：source环境变量文件、设置PATH、cd到脚本目录、确保日志目录存在。

第二，所有关键操作前加条件判断，不盲目往下执行。比如"备份完数据库再清理旧备份"，必须确认备份文件大小大于预期值才允许执行清理，否则可能把没备份成功的旧数据也清掉。

第三，脚本里的临时文件统一放到一个约定目录，并用PID做文件名后缀，避免多实例并发时互相覆盖。

第四，日志分级并且强制落盘。这看起来最简单，但多数脚本恰恰死在"没有日志"这一步。

第五，跟cron无关但很关键：修改脚本后先手动跑一遍，确认退出码是0，再用crontab -l确认配置实际生效的时间表达式。永远不要直接信任"我感觉改过了"。

其实排查cron问题这门手艺，到最后拼的不是你对某个命令有多熟，而是你的可观测性做得好不好：日志、状态文件、时间戳、环境快照，这些证据链越完整，定位问题的速度就越快。很多团队的定时任务管理混乱，很大程度上是"任务多、来源杂、缺少统一配置和观测入口"。有条件的话，建议团队内部做一个简单的"定时任务台账"：每台服务器上有哪些cron任务，分别做什么、负责人是谁、日志文件路径是什么、重启影响是什么。这个台账不需要做成复杂系统，一个Excel或者一页Markdown文档就够了，但在故障排查时能节省大量时间。

把这些外围工作做扎实了，你会发现"cron定时任务不执行"这个问题本身，并没有多可怕。它真正考验的是你在面对"一切看起来正常但结果不对"时的排查耐心和方法论。希望这篇长文能帮你节省几个深夜排查的钟头。