跳到主要内容

Cron 表达式解析

解析 Cron 表达式,算出接下来 5 次执行时间与可读含义

支持标准 5 字段与带秒的 6 字段两种格式逐个字段展开取值,星号与范围一眼看清算出接下来 5 次执行时间,时区可切换主动提示「日或周」语义陷阱这一最常见的坑

常用预设

字段解析

  • 分

    0

    取值

    0

  • 时

    9

    取值

    9

  • 日

    *

    取值

    不限制

  • 月

    *

    取值

    1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12

  • 周

    1-5

    取值

    1, 2, 3, 4, 5

含义

  • 09:00
  • 周一、周二、周三、周四、周五

接下来 5 次执行时间

  1. #12026-10-12 (Mon) 09:00
  2. #22026-10-13 (Tue) 09:00
  3. #32026-10-14 (Wed) 09:00
  4. #42026-10-15 (Thu) 09:00
  5. #52026-10-16 (Fri) 09:00

最后更新:2026-10-10

工具介绍

Cron 表达式最难的地方不是语法,而是几个反直觉的规则 —— 尤其是「日」与「周」同时指定时是「或」而不是「且」,以及星期日既可以是 0 也可以是 7。本工具把字段取值逐个展开,并把接下来 5 次执行时间算出来,让这些规则的影响直接看得见,而不用等到线上任务没按预期跑才发现。

功能特性

两种字段格式

自动识别 5 字段(分 时 日 月 周)与 6 字段(秒 分 时 日 月 周)格式,不用手动选择模式。

字段取值展开

把每个字段的实际取值完整列出来。`*/15` 到底会命中哪些分钟,列出来比在脑子里推更可靠。

下次执行时间

算出接下来 5 次执行的具体时间,支持切换时区。跨月、跨年、闰年 2 月 29 日这类边界都能正确计算。

或语义警告

「日」与「周」都不为 * 时,标准规定是「或」关系而非「且」。这个反直觉规则会导致日程完全跑错,工具会主动提示。

常用预设

内置每分钟、每小时、每天午夜、工作日 9 点、每月 1 号等常见配置,点一下即可套用再微调。

支持别名与月份缩写

@daily、@hourly 这类别名会先展开再解析;月份支持 jan、feb 等三字母缩写,星期支持 0-7(0 与 7 都是周日)。

怎么用

  1. 1

    输入表达式

    直接输入或从预设里挑一个。字段数量不对会明确提示应该是 5 个还是 6 个。

  2. 2

    检查字段展开

    对照每个字段展开后的取值确认是否符合预期,尤其是带步长或范围的写法。

  3. 3

    核对执行时间

    看接下来 5 次执行时间 —— 这是最直观的验证方式。跨月、跨年的边界情况在这里会暴露出来。

  4. 4

    确认时区

    服务器常用 UTC,而你可能在北京时间思考。切换时区后再核对一遍,能避免「差 8 小时」这类经典问题。

参数说明

字段顺序
标准格式为「分 时 日 月 周」5 个字段;带秒格式为「秒 分 时 日 月 周」6 个字段。本工具按字段数量自动识别。
星号 *
表示该字段不限制,取全部可能值。如在「分」字段表示每分钟。
范围 a-b
表示从 a 到 b 的闭区间。如「时」字段写 9-18 表示 9 点到 18 点每小时都执行。
步长 /n
配合 * 或范围使用,表示每隔 n 个单位。如「分」字段写 */15 表示第 0、15、30、45 分执行。
列表 a,b,c
用逗号列出多个值,也可与范围混用,如 0,10-12 表示第 0、10、11、12 分钟。
日与周的或语义
两个字段都不为 * 时,只要满足其中任意一个就会执行。如「0 0 13 * 5」表示每月 13 号**或**每周五执行,而不是两者都满足。这是 Cron 规范中的规定行为。
星期日
0 和 7 都表示周日,二者等价。本工具会把 7 归一为 0,因此两种写法算出的结果完全一致。
月份与星期缩写
月份支持 jan、feb 等三字母缩写(大小写不敏感);标准 Cron 中星期也支持 sun、mon 等,但不同实现的兼容性差异较大,建议直接用数字。

适用场景

  • 配置定时任务前先验证表达式是否符合预期
  • 排查「为什么任务没有按预期时间执行」
  • 确认带步长的表达式究竟会命中哪些时刻
  • 核对服务器 UTC 与本地时间的时区差异
  • 把从别人代码里复制来的表达式翻译成人话
  • 检查月末、年末这类边界日期是否正确触发
  • 了解「日」与「周」同时指定时的实际行为

常见问题

关于这个工具,你可能会问

为什么我的任务执行频率远超预期?

大概率踩了「日或周」的语义陷阱。当日与周两个字段都不为 * 时,Cron 规定是「或」而不是「且」—— 你写的 `0 0 13 * 5` 意思是「每月 13 号**或**每周五」执行,而不是「13 号且是周五」。想让日与周同时生效,需要借助其他机制或改用更明确的表达式。

* 和 ? 有什么区别?

在标准 Cron 里两者都表示「不限制」,本工具等同处理。区别在于某些实现(如 Quartz)要求「日」与「周」字段必须有一个写 ? 来明确表示「不设置该字段」,以避免或语义带来的歧义。标准 Cron 直接写 * 即可。

0 和 7 都表示周日吗?

是的,两者等价。这是历史遗留问题:早期实现用 0 表示周日,后来为了支持 1-7 的写法又引入了 7。本工具会把 7 归一为 0,所以两种写法得到的结果完全一致。

带秒的表达式怎么写?

在标准 5 字段前再加一个「秒」字段,变成 6 个字段。例如 `30 0 9 * * *` 表示每天 9 点 0 分 30 秒执行。注意并非所有调度器都支持秒级精度 —— 标准 cron 的最小粒度是分钟,Quartz、Spring 等框架才支持 6 字段格式。

怎么表达「每月最后一天」?

标准 Cron 没有直接的「月末」语法,写 31 会导致 2 月、4 月这类月份跳过执行。常见做法是用 `28-31` 配合脚本内部再判断一次,或者使用支持 L 语法的实现(如 Quartz 的 `L` 表示当月最后一天)。本工具不支持 L 语法,遇到会明确报错。

为什么 2 月 29 日的任务很少执行?

因为 2 月 29 日只在闰年存在,平均每 4 年才有一次。本工具的计算会正确跳过非闰年 —— 你可以用它验证下一次触发确实是一个闰年,而不是配置错了。

时区会影响执行时间吗?

会,而且影响很大。服务器通常使用 UTC,而你可能按北京时间思考,两者相差 8 小时。比如你想在北京时间 9 点执行,在 UTC 环境下应该写 `0 1 * * *` 而不是 `0 9 * * *`。本工具支持切换时区来核对。

表达式会被上传吗?

不会。解析与时间计算全部在浏览器本地完成,不产生任何网络请求。表达式里可能包含业务信息(比如凌晨 3 点跑对账任务),本工具不会接触这些内容。