下次运行时间用的是哪个时区？

所有时间都按浏览器本地时区计算和显示，会自动检测并以名称显示在结果上方。Cron 引擎也用同一个本地时钟来解释各字段。如果服务器按 UTC 运行任务，它的实际触发时间会与你看到的不同，除非你的浏览器也设在 UTC。

为什么像 0 0 9 * * 1-5 这样的六段表达式会失败？

这个计算器只接受五段：分钟、小时、日期、月份、星期。Quartz 和 Spring 会加一个开头的秒字段，有些调度器还会追加年份，所以从那些系统复制来的表达式会多出一到两列。计算前请先去掉秒字段（以及任何年份字段）。

分钟字段里的 */5 是什么意思？

步长语法 */5 表示在该字段的整个取值范围内每 5 个值匹配一次，所以在分钟字段里它匹配 0、5、10、15，一直到 55。这套语法在每个字段都适用：小时字段里的 */6 会在 0、6、12、18 点触发。

为什么 0 0 1 * 1 看起来比每月一次更频繁？

当日期和星期两个字段都被限定时，标准 cron 用「或」而不是「与」来组合它们。该表达式会在每月 1 号的午夜以及每个周一运行。要同时满足两个条件，你需要在任务内部加一层应用级判断。

改变系统时区会影响结果吗？

会，因为计算使用你按下计算那一刻的浏览器本地时区。把机器移到另一个时区或改动系统时钟，列出的时间点就会随之移动，即便表达式没有变。刷新页面即可采用新的时区。

为什么 0 9 * * 1-5 会跳过周六和周日？

第五个字段是星期，用 0 或 7 表示周日，一直到 6 表示周六。范围 1-5 选中周一到周五，所以周末被排除。自然语言描述也会把它确认为周一至周五。

Cron 下次运行计算器

粘贴任意标准 Cron 表达式，立刻看到它的自然语言含义以及接下来十次触发时间，全部按你自己的时区显示。这是在把调度部署到 crontab、GitHub Actions 或 CI 流水线之前验证它的最快方式。一切都在你的浏览器里运行，来自私有基础设施的调度绝不会被发送到任何地方。

如何使用

在输入框里输入五段表达式，然后点击计算或按回车。描述卡片会渲染一段自然语言摘要，下次运行列表显示十个绝对时间戳，每个都带「3 小时后」这样的相对倒计时。列表上方会显示时区名称，告诉你这些时间对应哪个时钟。七个预设覆盖最常见的调度——每分钟、每五分钟、每小时、每天 09:00、工作日 09:00、每周一以及每月 1 号——点击其中一个会立即重新计算。使用复制按钮可以把十个格式化时间作为文本取走，贴进工单或运维手册。

五个字段

Cron 表达式是由空格分隔的五个字段，从左到右依次读取：分钟（0–59）、小时（0–23）、日期（1–31）、月份（1–12）和星期（0–7，其中 0 和 7 都表示周日）。每个字段可以填单个值（30）、通配符（*）、列表（1,15）、范围（1-5）或步长（*/10）。字段之间可以是任意空白，所以多余的空格能被容忍，但字段数量必须正好是五个。

这个工具组合了两个久经考验的库：一个生成人类可读的描述，另一个完整的 cron 引擎计算实际触发时间。第二部分很重要，因为描述可能看起来没问题，而时间却暴露出范围里的差一错误或字段放错位置。

实操示例

假设现在是 2026 年 9 月 11 日星期五下午，浏览器使用本地时间。

0 9 * * 1-5 — 「在上午 09:00，周一至周五」。接下来的运行时间是 9 月 14 日周一、15 日周二、16 日周三、17 日周四和 18 日周五，都在 09:00。周六和周日不出现，印证了工作日的范围。

*/15 * * * * — 「每 15 分钟」。列表从下一个刻钟开始，按 15 分钟步进。

0 0 1 * 1 — 这就是「或」的情况。它会在 9 月 14 日周一午夜触发，接着是 21 日周一和 28 日周一，再下一次是 10 月 1 日周四，因为每月 1 号落在那天周四。看到 1 号从周一的序列中跳出来，是理解「或」行为最直观的方式。

30 6 1,15 * * — 「在上午 06:30，每月 1 号和 15 号」。这个模式适合半月一次的薪资或账单任务。

特殊语法一览

字段	位置	允许的值	实用模式
分钟	1	0–59	`*/5`、`0,30`、`15-45`
小时	2	0–23	`*/6`、`9`、`9-17`
日期	3	1–31	`1`、`1,15`、`*/2`
月份	4	1–12	`1`、`1-6`、`*/3`
星期	5	0–7（周日 = 0 或 7）	`1-5`、`1,3,5`、`0`

步长可以和范围组合，所以分钟字段里的 10-50/10 会匹配 10、20、30、40 和 50。列表和范围也能混用，例如 0 8,12,18 * * 1-5。逗号、连字符和斜杠语法就是这门语言的全部；除此之外的东西，例如 Quartz 的 L、W 或 # 记号，在这里不受支持，应改写或在能理解它们的调度器里测试。

日期与星期是「或」的关系

这是 cron 里最出人意料的一条规则，也是大多数调度 bug 的来源。当两个日期字段中有一个是通配符时，另一个正常控制调度：0 0 * * 1 表示每周一运行。但当两者都被限定时，标准 cron 用「或」来对待它们，所以 0 0 1 * 1 的含义是「1 号，或任意一个周一」，而不是「1 号且恰好是周一」。

在表达式内部没有标准语法能强制「与」。常见的变通办法是让任务每天运行，除非日期同时满足两个条件就提前退出，或者用两个独立的定时任务触发同一条命令。查看计算出的列表，是判断你的表达式是否真的在「或」的最快方式。

常见错误

字段数量不对。 四段或六段都会校验失败。先数一数列数，再怀疑语法有问题。
忘了星期从周日开始。 1 是周一不是周日，而 0 和 7 都表示周日。
把分钟和小时的位置弄反。 30 9 是 09:30；9 30 无效，因为小时 30 超出范围。
假设使用 UTC。 CI 平台和服务器经常跑在 UTC，而你的浏览器不是，所以同一表达式会在不同的本地墙上时间触发。
以为两个被限定的日期字段是「与」。 如上所述，默认是「或」；需要同时满足时加一层任务内判断。
只信描述。 也要读计算出的时间；它们能暴露文字描述可能掩盖的范围错误和「或」错误。