Crontab 生成器与 Cron 表达式构建工具

什么是 Cron 表达式？

# Linux crontab entry — runs every 15 minutes
*/15 * * * *  /usr/local/bin/poll-api.sh

# Kubernetes CronJob — weekdays at 9:00 AM UTC
apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-report
spec:
  schedule: "0 9 * * 1-5"
  timeZone: "UTC"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: report
              image: report-runner:1.0
          restartPolicy: OnFailure

# GitHub Actions workflow — hourly
on:
  schedule:
    - cron: '0 * * * *'

# AWS EventBridge — first of each month
ScheduleExpression: cron(0 0 1 * ? *)
# (Note: AWS uses the Quartz 6-field form with '?' for day-of-week)

核心特性

Cron 变体与调度器

Cron 表达式示例

*/15 * * * *

0 9 * * 1-5

0 0 1 * *

*/5 9-17 * * 1-5

0 0 1 JAN,APR,JUL,OCT *

0 0 1 * 5

30 2 * * *

@daily

如何构建 Cron 表达式

1. 1

   键入或粘贴 cron 表达式

   在顶部输入框中输入一个五字段 cron 表达式（例如 `*/15 * * * *`）。工具会随键入实时解析与校验——有效则显示绿色对勾，无效则显示红色提示并指出出错字段。`@daily`、`@hourly` 等宏也可接受。

2. 2

   或微调五个字段输入

   不用背字段顺序——通过标注好的输入框分别编辑「分钟」「小时」「日」「月」「星期」。顶部完整表达式会自动更新。用 `*` 表示通配，`*/N` 表示步长，`a-b` 表示区间，`1,3,5` 表示列表。

3. 3

   点选预设快速起步

   点击任意预设按钮（每 15 分钟、工作日上午 9 点等）即可载入一个常用排程，然后再按需微调字段。11 个预设覆盖了生产环境里真正会用到的模式。

4. 4

   核对下次运行预览

   查看接下来五次的运行时刻——切换「本地」与「UTC」确认排程在你期望的时刻触发。这是部署前发现 POSIX「日/星期」OR 陷阱最可靠的方法。

5. 5

   复制并粘贴到调度器

   点击「复制」获取表达式。粘贴到 crontab、systemd timer、GitHub Actions 的 `cron:`、AWS EventBridge、Kubernetes CronJob 的 `schedule`，或任何兼容 cron 的调度器。别忘了确认目标调度器的时区——参见下文「最佳实践」。

常见 Cron 错误

# 本意：「每月第一个周五」
0 0 1-7 * 5
# 实际：每月 1 日到 7 日的所有日子，或者每个周五——两个条件都会触发

# 用外层脚本实现真正的 AND 语义
0 0 * * 5  [ $(date +\%d) -le 7 ] && /your-script
# 或者放弃一个条件，接受更宽松的排程

# 美东开发者写好后部署到 UTC 服务器
0 9 * * *  /your-report.sh
# 实际在 UTC 9 点触发 = 美东凌晨 4 点 —— 不是开发者的本意

# 锁定时区，或直接按 UTC 编写
CRON_TZ=America/New_York
0 9 * * *  /your-report.sh

# 本意：每 15 分钟
15 * * * *
# 实际：每小时一次，仅在第 15 分钟触发（每小时少了 3 次）

# 正确写法
*/15 * * * *
# 每 15 分钟：每小时的第 0、15、30、45 分钟

# Quartz 六字段被复制进 Linux crontab
0 0 9 * * 1-5
# Linux 解析为：分=0、时=0、日=9、月=*、星期=1-5
# = 月份匹配星期的每月 9 日 0 点 —— 完全乱了

# POSIX 五字段，去掉首位秒
0 9 * * 1-5
# = 工作日上午 9:00

# 2 月 30 日或 31 日 —— 永远不会运行
0 0 30 2 *
0 0 31 2 *
# 能解析，但永远没有排程触发

# 用脚本配合实现「2 月最后一个工作日」
0 0 28-29 2 *  [ $(date -d tomorrow +\%m) = 03 ] && /your-script

# Quartz：「每月最后一个周五」—— POSIX 无效
0 0 ? * 6L *

# 用 POSIX 外层脚本实现「最后一个周五」
0 0 25-31 * 5  /your-script
# 在任意月份的 25-31 日且为周五时运行

常见使用场景

Linux Crontab 任务

构建并验证 `/etc/crontab`、`/etc/cron.d/*` 或单用户 `crontab -e` 中的条目。保存前先用下次运行预览确认排程在服务器配置时区下落在预期时刻。

Kubernetes CronJob 排程

生成 Kubernetes CronJob 的 `spec.schedule` 字段。Kubernetes 1.27+ 还支持 `spec.timeZone`——切到 UTC 设计你的排程，然后显式设置 `timeZone`，避免被工作节点的本地时间带偏。

GitHub Actions 定时工作流

构建 `on.schedule` 下的 `cron:` 条目。GitHub Actions 始终运行在 UTC——把预览切到 UTC 来确认你的排程。避免小于 15 分钟的间隔；GitHub 调度器在负载下会跳过短间隔任务。

AWS EventBridge 规则

为 EventBridge 定时规则构造 cron 表达式。注意：AWS 使用 Quartz 风格的六字段语法，「星期」用 `?`——本工具输出 POSIX 五字段，你需要在前面补一位秒（`0`），并把两个「日」字段中只有一个限定时另一个的 `*` 换成 `?`。

GitLab CI 定时流水线

校验 GitLab 定时 CI 流水线的 cron 表达式。GitLab 使用 POSIX 五字段语法——正是本工具输出的形式。GitLab 也提供 UI 日期选择器，但 cron 形式在非标准间隔下能给你更精细的控制。

Cloudflare Workers Cron Triggers

构造 `wrangler.toml` 里的 `[triggers.crons]` 条目。Cloudflare 使用 POSIX 五字段语法，最小间隔为 1 分钟，worker 运行在 UTC。用预览确认触发落在预期窗口内。

Node.js node-cron 排程

为 `node-cron` 库构建表达式——它同时支持五字段 POSIX 和可选的首位秒字段。除非真的需要亚分钟精度，否则建议坚持五字段；六字段表达式无法搬到 Linux crontab。

代码评审与文档

把 PR 或 runbook 里的 cron 表达式粘进来，立刻知道它在做什么——不必再对着 `30 7 * * 1-5` 苦思，也不用翻参考卡片。中文描述也很适合放在内联注释和 README 中。

Cron 语法参考

字段顺序：分 时 日 月 星期

分（0-59）、时（0-23）、日（1-31）、月（1-12）、星期（0-6，7 也表示周日）。「星期」字段同时接受数字（0-6）和英文缩写（SUN-SAT，大小写不敏感）。

运算符

`*` = 任意值；`,` = 列表分隔（`1,3,5`）；`-` = 区间（`1-5`）；`/` = 步长（`*/15`、`5/10`）；名称：月份 JAN-DEC、星期 SUN-SAT（大小写不敏感）。

宏（别名）

`@yearly` = `0 0 1 1 *`；`@annually` = `0 0 1 1 *`；`@monthly` = `0 0 1 * *`；`@weekly` = `0 0 * * 0`；`@daily` = `0 0 * * *`；`@midnight` = `0 0 * * *`；`@hourly` = `0 * * * *`。`@reboot` 是特殊的非排程宏（仅在系统启动时运行），会被本工具拒绝并附说明。

POSIX 日/星期语义（OR 规则）

当「日」和「星期」都被限定（都不是 `*`）时，只要其一匹配，排程就会触发——OR 语义。仅其一被限定时，由该字段决定。两者都是 `*` 时，每天都匹配。这条 OR 规则适用于 vixie cron、BSD cron 和大多数 POSIX 实现；Quartz 则用 `?` 来在 AND 与 OR 之间消歧。

六字段模式（Quartz-Lite）

如果输入有六个空格分隔的 token，本工具会把首位当作秒字段（0-59）。这对 Quartz、Spring `@Scheduled(cron=...)` 和 node-cron 很有用。不可移植到 Linux crontab 或 POSIX 调度器——它们会把你的「秒」当成「分」，把后续字段整体往前错一格。

步长运算符的锚定

`*/N` 锚定到字段的最小值：分钟里的 `*/15` = `0,15,30,45`，而不是「从现在起每 15 分钟」。基准非通配时：分钟里的 `5/15` = `5,20,35,50`。如果步长不能整除字段区间，在回绕处会跳过——这是正确行为，不是 bug。

校验边界

分 ∈ [0,59]、时 ∈ [0,23]、日 ∈ [1,31]、月 ∈ [1,12]、星期 ∈ [0,7]。超出范围的值会产生字段级错误。「日」不会按实际月份校验（`0 0 31 2 *` 能正常解析，但永远不会触发，因为 2 月没有 31 日——下次运行预览会显示「未来 4 年内无运行计划」）。

拒绝 Quartz 运算符

POSIX cron 不支持 Quartz 的 `?`（无特定值）、`L`（last）、`W`（最近工作日）和 `#`（每月第 n 个星期几）。本工具会以明确的「不支持 Quartz 运算符」错误信息拒绝它们，而不是悄悄按 POSIX 解析失败。Quartz 排程请用 Quartz 感知的工具或 Spring 调度器。

下次运行搜索的年份上限

下次运行计算最多向前搜索 4 年；触发频率比这更低的表达式（例如「2 月 29 日」模式）会显示「未来 4 年内无运行计划」。这是为了避免在不可能匹配的模式上无限迭代而做的设计。

Cron 排程最佳实践

服务器统一 UTC，显示时再转本地

把服务器设为 UTC（`/etc/timezone` 或 `TZ=UTC`），所有 cron 表达式都按 UTC 编写。只在 dashboard 和报表展示时转换为本地时间。这能消灭一整类时区 bug——它们在夏令时切换时危害最大，本地时间排程会无声地重复触发或漏跑。借助本工具的 UTC 开关，从一开始就按 UTC 设计排程。

避开 POSIX「日/星期」OR 陷阱

除非你确实想要 OR 语义，否则永远不要同时限定「日」和「星期」。如果想要「一月份的每个周一」，写 `0 0 * 1 1`（「日」是 `*`）；想要「每月 1 日」，写 `0 0 1 * *`（「星期」是 `*`）。POSIX 的 OR 规则会让 `0 0 1 * 1` 在每月 1 日和每个周一都触发——几乎不可能是你的本意。部署前先看下次运行预览，就能及时捕获这种问题。

在排程定义里显式锁定时区

现代调度器都支持在排程定义里固定时区：crontab 顶部加 `CRON_TZ=America/New_York`（vixie cron 3.0+）；Kubernetes CronJob 1.27+ 用 `spec.timeZone: "America/New_York"`；AWS EventBridge Scheduler 在排程表达式上配 `ScheduleExpressionTimezone`。显式锁定时区，不要依赖服务器默认——基础设施迁移时服务器时区可能毫无征兆地变化。

把负载分散到不同分钟，避免都堆在 :00

非关键任务避免使用 `0 * * * *`（每小时第 0 分钟）——规模上来后，所有事情都挤在 :00 会造成负载尖峰。为每个任务挑一个随机分钟偏移（`23 * * * *`、`41 * * * *`）来分散压力。每日任务同理：当大量任务都赶在 3:00 时，`30 3 * * *` 比 `0 3 * * *` 对数据库更友好。

让任务幂等

cron 没有内建重试、没有重叠保护、没有错过恢复。你的任务必须能安全地多次运行（幂等）并自我检查。与其写「上午 9 点发送报表」，不如写成「如果今天的报表还没发，就发送」——这能在宕机、误重复排程、并发触发后自愈。幂等是任务自身的属性，不是调度器的属性，也是最重要的可靠性实践。

为关键排程加心跳监控

cron 最大的弱点就是静默失败——排程没触发时，没有任何提示。关键任务可以在执行结束时给心跳服务（Healthchecks.io、Cronitor、Dead Man's Snitch）发一次 ping；预期 ping 没到时，服务会告警。这能同时捕获「任务失败」和「排程根本没触发」两种情况。免费额度足以覆盖个人和小团队的常见需求。

上线前用下次运行预览核对一遍

部署新 cron 排程前，先看本工具预览里接下来的五次运行时刻，切换「本地」与「UTC」核对。确认排程落在你期望的时刻——不会提早五分钟、不会跑错日子、不会漏掉你在意的周末。预览是成本最低的「生产环境测试」。

常见问题