0 9 1-7 * * 在 Cron 表达式解析中打开 写成 0 9 1-7 * 1 不行:日和星期都设置时,cron 只要其中一个匹配就运行,结果会在 1–7 号和每个周一都运行。Quartz 和 Spring 支持 MON#1。
逐字段解释
| 字段 | 值 | 匹配 |
|---|---|---|
| 分钟 | 0 | 0 |
| 小时 | 9 | 9 |
| 日 | 1-7 | 1, 2, 3, 4, 5, 6, 7 |
| 月 | * | 任意值 |
| 星期 | * | 任意值 |
接下来的运行时间
示例:2026年1月1日 之后的前 6 次运行(UTC)。
- 2026年1月5日周一 09:00
- 2026年2月2日周一 09:00
- 2026年3月2日周一 09:00
- 2026年4月6日周一 09:00
- 2026年5月4日周一 09:00
- 2026年6月1日周一 09:00
各平台写法
crontab
0 9 1-7 * * [ "$(date +\%u)" = 1 ] && /path/to/command 用 crontab -e 添加这一行。除非设置了 CRON_TZ 或 TZ,否则按服务器时区运行。
Kubernetes CronJob
apiVersion: batch/v1
kind: CronJob
metadata:
name: first-monday-of-month
spec:
schedule: "0 9 1-7 * *"
timeZone: "Etc/UTC"
concurrencyPolicy: Forbid
jobTemplate:
spec:
template:
spec:
restartPolicy: OnFailure
containers:
- name: job
image: busybox:1.36
command: ["/bin/sh", "-c", "date; echo run"] 设置 spec.timeZone(Kubernetes 1.27+);不设置时按 controller manager 的时区,通常是 UTC。
GitHub Actions
on:
schedule:
- cron: '0 9 1-7 * *'
workflow_dispatch: GitHub Actions 始终使用 UTC,最短间隔为 5 分钟,负载高时定时任务可能延迟启动。
Quartz
0 0 9 ? * MON#1 Quartz 把秒放在最前面,并且日和星期中必须有一个写 ?。星期用 1–7 表示(从周日开始),用英文缩写更不容易出错。
Spring
@Scheduled(cron = "0 0 9 * * MON#1") Spring 的 @Scheduled(cron = …) 使用六个字段:秒,再加上常规的五个字段。
常见问题
› 为什么 0 9 1-7 * 1 运行得太频繁?
日和星期两个字段都受限时,cron 按“或”处理,所以会在 1 到 7 号运行,也会在每个周一运行。
› 0 9 1-7 * * 按哪个时区运行?
Cron 使用运行它的机器或服务的时区。在 Linux 上是系统时区,除非设置了 CRON_TZ 或 TZ;Kubernetes CronJob 可以设置 spec.timeZone;GitHub Actions 始终使用 UTC。
› 部署前怎么检查这个计划对不对?
在本站的 Cron 表达式解析中打开 0 9 1-7 * *。它会解释每个字段,并按本地时间或 UTC 列出接下来的运行时间,全部在浏览器里完成。