Cron 表达式看不懂？把 0 9 * * 1-5 翻成人话 - 粘贴一行，看见接下来 5 次执行时间

TL;DR

• cron 不生效，九成是两条默认规则没搞清：五段和六段不是一回事，日期和星期同时写是「或」。
• 0 0 1 * 1 不是「每月 1 号而且是周一」，是「1 号，或者任意一个周一」。
• 看懂表达式最快的办法不是背语法，是让它把接下来 5 次执行时间算出来。
• 做了个页面：粘贴就翻译、逐段拆解、按你时区算时间，反过来说一句「每个工作日 8 点半」也能生成，点这里直接用。

一、那次事故，是少写了一个星号

凌晨两点，报表任务没跑。日志一片空白，连报错都没有，说明它压根没启动。

最后查出来：crontab 里少了一个星号。四段而不是五段，Linux 不报错，任务一动不动，安安静静躺了三天。

这就是 cron 的脾气。它不说话，要么跑，要么不跑。

二、五段和六段，是两个物种

标准 crontab 是五段：分、时、日、月、周。Linux、macOS、大多数云厂商的定时任务都按这个来。

Quartz 和 Spring 是六段，最前面多一个秒位。你把六段贴进 Linux，它当场报语法错误；把五段丢给 Spring，它按秒位解析，整体错位一列。

从哪儿抄的，就得往哪儿放。这句话能省掉一半排查时间。

三、日期和星期同写是「或」，不是「与」

这条最容易翻车。很多人把 0 0 1 * 1 理解成「每月 1 号，且那天是周一」，也就是每月第一个周一。

实际含义是「每月 1 号，或者任意一个周一」。一个月里它至少跑四五次，你以为在找 bug，其实是规则读反了。

标准 cron 表达不了「每月第一个周一」。要么在脚本里判断日期，要么换 Quartz 的 # 语法。别硬凑，凑出来的范围只会更宽。

四、与其背语法，不如让它自己算

语法表看三遍也记不住，但「接下来 5 次分别是什么时候」一眼就懂。

页面做三件事：粘贴即翻译，逐段告诉你每个数字管什么，再按你电脑的时区列出接下来 5 次。每次下面都标了 UTC 时刻，服务器日志跑 UTC 时直接对，不用心算八小时。

算不出来也会直说。比如 2 月 30 日，它明确告诉你这个规则永远不会触发，而不是装作能跑。

五、反过来也能用

想不出怎么写的时候，直接说人话：「每个工作日早上 8 点半」，它给你 30 8 * * 1-5。英文也一样，every weekday at 8:30 am 照样认。

生成完还是同一个页面在解释，顺手就能确认对不对。

常见疑问

我的表达式是 6 段、带秒的，能用吗？能。Quartz 和 Spring 会在最前面多一个秒位，页面会自动忽略它、按标准 5 段计算，并在结果上方提示你确认目标平台。反过来，把 6 段直接贴进 Linux 的 crontab 会报错，所以要看清你用的是哪个。

算出来的时间跟服务器日志差 8 小时？页面按你设备的时区算，服务器多数跑 UTC。每次执行时间下面都标了 UTC 时刻，直接拿去和日志对。差 8 小时是时区问题，不是表达式写错。

「每月第一个周一」怎么写？标准 cron 写不出来。0 9 1-7 * 1 得到的是「1 到 7 号，或者任意周一」，范围反而更宽。要精确只能在脚本里判断日期，或者换 Quartz 的 # 语法。页面遇到这种组合会提示你。

页面会保存我输入的表达式吗？不会。全部在你的浏览器里算，不发任何请求，也没有记录，刷新就没了。crontab 里常带路径和账号，不用担心被留下来。

English version: https://www.9314.cn/tools/cron-translator/en/