Cron 表达式解析器

五个字段，越往后越粗

在一个字段内部：* 表示任意，, 列举取值，- 给出一个范围，/ 表示步进。分钟字段里的 */15 是每十五分钟一次；5/10 表示从 5 开始每隔十，也就是 5、15、25 等等。范围可以绕回，所以 FRI-MON 是表示「周末连着它两头」的合法写法。

那条把所有人都坑过的规则

这是本页唯一真正值得你带走的东西。

当「日」和「星期」两个字段都被限定时，cron 会在其中任意一个匹配时运行任务。不是两个都匹配。它是一个「或」，读起来却像一个「且」。

0 0 1 * MON   # NOT "the 1st, if it is a Monday"
              # Actually: every 1st, AND every Monday

那条排程一个月大约触发五次。把它粘进上面的解析器，看看接下来的运行时间——那个序列立刻就露馅了。

这条规则只在两个字段都被限定时才适用。如果其中任一个是 *，另一个说了算，这就是为什么 0 0 * * MON 的行为完全符合预期。这个行为写在 POSIX 规范里，所有主流 cron 都这么实现，所以它不是一个你能靠配置绕开的 bug。

要真正做到两个条件同时成立，就在排程里限定一个字段，另一个在任务开头自己判断：

0 0 * * MON  [ "$(date +\%d)" = "01" ] && /usr/local/bin/job

夏令时，它每年会弄坏你的任务两次

除非另有指定，cron 跑在服务器的本地时区里，而本地时间并不是连续的。时钟往前拨时，有一个小时凭空消失：一个排在 02:30 的任务可能被整个跳过，也可能在 03:30 才触发，取决于你用的是哪个 cron。时钟往回拨时，01:30 会出现两次，任务也可能跟着跑两次。

现代的 Vixie cron 会做些努力——因为向前跳而错过的任务，通常事后会补跑一次——但这个行为在各实现之间并不一致，而容器调度器又是另一套。

长久的解决办法是让调度器跑在 UTC 上，只在边界处做转换。Kubernetes 的 CronJob 默认用 UTC，正是出于这个原因。如果某个任务必须在某个特定的本地时间运行，那就接受它一年里有一部分时间会差一小时，或者换一个真正懂时区的调度器——systemd 的定时器就懂。

cron 任务跑不起来的其他原因

• 环境几乎是空的。 cron 不会加载你的 shell 配置文件，所以 PATH 很简陋，你的虚拟环境也没有激活。永远用绝对路径。
• 一个裸的百分号。 在 crontab 里，% 表示换行。date +%Y 会悄无声息地坏掉；它必须写成 date +\%Y。
• 结尾没有换行。 有些 cron 会忽略 crontab 里最后一行，如果那一行没有以换行结尾的话。
• 输出无处可去。 cron 会把输出邮寄给用户，而如果邮件没配好，它就消失了。重定向到一个日志文件，好让失败看得见。
• 运行相互重叠。 cron 不会等上一次跑完。一个耗时五分钟的任务排在每分钟一次的表上，会不断堆积，直到某个东西垮掉。用 flock。

cron 表达不了什么

各字段是彼此独立的，所以任何不能整除一小时或一天的东西都够不着。「每 90 分钟」写不出来。标准 cron 里也写不出「每月最后一个星期五」——那正是 Quartz 的 L 和 # 存在的理由，也是它们不可移植的原因。

如果你发现自己在和这套语法搏斗，那通常就是该换一个按时间间隔而不是按日历字段思考的调度器的信号。一个写着 OnUnitActiveSec=90min 的 systemd 定时器，一行就说清了你的意思。

相关

上面的运行时间是 UTC 的——时间戳转换器会把其中任意一个换算到你自己的时区，或者换成你的调度器记日志所用的任何格式。如果你要的是匹配文本而不是排程，正则测试器就在隔壁。