Cron 表达式生成器
在 Quartz 6 字段和 Unix 5 字段之间切换，快速生成可部署的定时表达式，并提前核对执行时间。
0 */5 * * * ?原始表达式
把现有 cron 表达式贴进来，直接回填到构建器中。
调度构建器
熟悉语法时可直接编辑字段，不熟悉时建议先从预设开始。
语法速览
下面这几种写法，已经覆盖了大多数生产环境的 cron 场景。
*/5例如 */5 表示每隔 5 个单位执行一次，常用于每 5 分钟。
1-5例如 1-5 表示连续区间，适合工作日或月份范围。
MON,WED,FRI例如 MON,WED,FRI 表示多个离散值组合。
?Quartz 常用 ? 表示该字段不参与匹配，避免日与周同时约束。
自然语言解释
每 5 分钟执行一次
Quartz 模式更适合带秒字段的调度器，例如 Spring / Quartz。若你最终部署到 Linux 或 Kubernetes，请先切换成 Unix 模式再确认表达式。
未来 5 次执行时间
字段说明
0-59控制一分钟中的秒值，仅 Quartz 模式使用。
0-59控制每小时中的分钟值。
0-23控制 24 小时制中的小时值。
1-31控制每月中的日期。在 Quartz 中通常需要和周字段配合 ? 使用。
1-12 or JAN-DEC控制月份，可使用数字或月份英文缩写。
0-7 or SUN-SAT控制星期，可使用数字或星期英文缩写。
特殊符号说明
*匹配该字段中的所有可能值。
*/n按照固定步长重复执行，例如每隔 5 分钟。
a-b匹配起止边界之间的连续值。
a,b,c在同一字段中匹配多个明确值。
?Quartz 专用，占位表示该字段不参与调度匹配。
常见调度模板
直接从真实业务场景出发，比从 6 个字段空白开始更高效。
这个 Cron 页面解决什么问题
Cron 语法很短，但出错代价很高。字段顺序一旦写错，原本”每 5 分钟执行”就可能变成”每月一次”。这个页面的目标就是缩短排错路径：你一边构建表达式，一边立即看到最终结果和预测执行时间。
页面同时支持 Unix 5 字段和 Quartz 6 字段，因此既适用于 Linux 服务器、Kubernetes CronJob，也适用于 Spring / Quartz 一类带秒字段的调度系统。
如何使用此工具
先选择与你目标平台一致的 cron 模式，然后从预设开始，或者直接编辑每个字段。表达式会立即更新；如果你手头已经有现成的 cron 字符串，也可以粘贴到”原始表达式”区域，再回填到构建器中查看。
准备部署前，务必先阅读自然语言解释，并核对未来 5 次执行时间是否与预期一致。这一步最能帮你发现字段顺序错误、星期理解错误以及平台模式选错的问题。
上线前注意事项
- Cron 的实际触发时间始终依赖调度器所在机器的时区，部署前请先确认服务器时区。在 Kubernetes CronJob 中，默认使用 UTC 时区，可通过 spec.timeZone 显式指定。
- Unix cron 和 Quartz cron 默认并不通用，必须先确认目标平台到底需要 5 字段还是 6 字段。切换到错误模式会导致任务不执行或执行频率异常。
- 在 Quartz 中，日字段和周字段经常配合 ? 使用，避免两个字段同时对调度结果施加约束。Unix cron 不支持 ?，日和周任一字段满足条件即触发。
- 本页覆盖的是最常见 cron 语法。若你的平台支持更特殊的扩展写法（如 @yearly、L/W 等），仍建议在目标环境中再验证一次。
- 在 Shell 或 YAML 中编写 cron 表达式时，注意 * 和 / 等特殊字符的转义。例如在 Kubernetes CronJob YAML 中，表达式需用引号包裹，避免 YAML 解析器误处理。
- 首次部署新 cron 任务时，建议先用”每分钟执行一次”做临时测试，确认任务本身能正常运行后，再替换为真正的调度频率。
典型生产场景
以下是 DevOps 日常最高频的几种调度模式，可参考表达式直接套用或按需微调。
Quartz: 0 0 2 * * ?Unix: 0 2 * * *在业务低谷期（通常凌晨 2 点）触发全量构建或集成测试，避免占用白天的 CI 资源配额。如果构建耗时较长，建议同时设置任务超时上限，防止异常构建持续占用资源导致后续任务堆积。
Quartz: 0 30 1 * * ?Unix: 30 1 * * *凌晨 1:30 执行全量备份，确保在早高峰到来前完成并验证完整性。结合 --single-transaction（MySQL）或 pg_dump 保证备份的一致性快照，备份完成后应有日志或告警通知确认结果，切勿只写脚本不验证。
Quartz: 0 0 3 * * ?Unix: 0 3 * * *Let's Encrypt 证书有效期 90 天，certbot 仅在距到期不足 30 天时才真正执行续签。每天凌晨 3 点尝试是安全策略——多数情况下任务无感退出，只在临近到期时触发续签。续签完成后需 reload 或重启 Web 服务器（如 nginx -s reload），使新证书立即生效。
Quartz: 0 5 0 * * ?Unix: 5 0 * * *设置 00:05 而非 00:00，可以避免与其他整点任务竞争资源，同时给前一天的日志写入留出 5 分钟缓冲，确保上一天的日志已完整落盘。实践中常与 logrotate 工具配合使用，logrotate 负责切割文件，cron 负责调度时机。
Quartz: 0 50 7 * * 1-5Unix: 50 7 * * 1-5对于工作日早 8 点流量集中的业务（如 B2B SaaS、企业内网工具），提前 10 分钟在 07:50 触发预热脚本，可显著降低早高峰期间的缓存穿透率和数据库峰值压力。仅对工作日执行（1-5），周末跳过，减少不必要的资源开销。
Quartz: 0 */5 * * * ?Unix: */5 * * * *每 5 分钟对关键服务发送 HTTP 探针或 TCP 探测，是最基础的可用性监控手段。自托管健康检查脚本可在内网运行，不依赖公网可达性，特别适合私有化部署场景。但需注意告警收敛机制，避免短暂网络抖动触发大量重复告警。
常见 Cron 表达式示例速查
下面整理了最常被搜索的 cron 表达式写法（均为 Unix 5 字段格式），可直接复制使用，或粘贴到上方构建器中查看自然语言解释与未来执行时间。
*/5 * * * **/5 表示分钟字段每隔 5 个单位触发，是健康检查、探针、轻量轮询最常用的频率。改成 */10、*/15 即可调整为每 10、15 分钟一次。
0 * * * *分钟为 0、小时为 *，即每个整点触发一次，常用于整点统计与缓存刷新。每 2 小时则写 0 */2 * * *。
0 0 * * *0 0 表示每天 00:00 触发，适合按天聚合的批处理，等价于 crontab 的 @daily。
0 2 * * *业务低谷期执行全量备份、夜间构建的经典时间，避开白天高峰占用资源。
0 9 * * 1-5星期字段 1-5 表示周一到周五，跳过周末，适合工作日报表与上班前缓存预热。
0 8 * * 1星期字段为 1 表示周一（0 和 7 都表示周日），常用于生成周报与周度清理任务。
0 0 1 * *日字段为 1，表示每月第一天 00:00 触发，适合月度账单与月初归档，等价于 @monthly。
0 0 * * 0星期字段为 0 表示周日，常用于每周全量备份与周末维护窗口任务。
时区陷阱详解
Cron 本身不感知时区——触发时间完全由调度器所在系统的时钟决定。这一点在容器化和多区域部署中是最常见的故障根因之一：你写的是”早 8 点”，服务器运行的是”UTC 8 点”，实际触发时间却是你本地时间的下午 4 点。
Docker 容器默认继承宿主机时区，但大多数云主机（AWS EC2、GCP Compute Engine、阿里云 ECS）出厂时默认配置为 UTC，而非用户本地时区。部署前请用 date 命令确认系统当前时间，用 timedatectl 查看完整时区配置，两步缺一不可。
Kubernetes 在 v1.27 之前，所有 CronJob 统一使用 UTC 计时，不提供任何时区选项。v1.27+ 正式引入 spec.timeZone 字段，支持直接填写 IANA 时区标识符，如 Asia/Shanghai 或 America/New_York。如果你的集群版本低于 1.27，唯一的解决方案是在表达式中手动换算 UTC 偏移量，并在代码注释中注明原因，避免后人误改。
夏令时（DST）是另一个高风险区间：春季时钟向前拨 1 小时时，凌晨 2:00～3:00 之间的时间点在当天不存在，落在该区间的 cron 任务会被调度器直接跳过；秋季回拨时，该区间重复出现，任务可能触发两次。生产环境建议将关键任务的执行时间设在凌晨 1:00 之前或 3:30 之后，彻底规避 DST 模糊区间。