Cron 调试流程

未经验证就上线 cron，团队往往要到备份在中午而非午夜跑时才发现。把调度当代码：解析、解释、预览。

第一步：规范化表达式

• 仅五字段（除非平台文档写明六字段）
• 无多余空格；注释单独成行（crontab 里 # backup job，不要写在字段内）
• 勿把 Quartz 的 ? 与 Unix cron 混用

粘贴到解析器，阅读 逐字段说明。

第二步：阅读人类可读描述

好的描述应回答：

• 哪些分、时触发？
• 日与周是否同时受限——是否 OR 语义？
• 这是「工作日上午」还是更复杂的组合？

若摘要与意图不符，部署前先改字段。

第三步：预览下次执行

在以下时区各生成至少 3–5 次 upcoming 时刻：

• 平台实际执行时区
• UTC（便于对日志与 Actions）

对照日历——尤其月末、夏令时切换、短月份。

第四步：对照平台文档

问题	动作
GitHub Actions？	默认 UTC
K8s CronJob？	显式设置 timeZone
Linux crontab？	查服务器 timedatectl
六字段引擎？	翻译，勿盲拷

常见错误清单

错误	现象
周日 7 vs 0 混淆	星期 off-by-one
日+周同时设却期望 AND	多触发
分钟字段 */60	非法或空调度
本地 9 点写成 UTC Actions	墙钟时刻错
长任务 + 短间隔	执行重叠

第五步：写入运行手册

记录表达式、时区、平台、负责人与预期耗时。链到能证明上次成功的监控。

要点

解析 → 描述 → 预览 → 文档化。任一步与预期不符就停。Cron 的 bug 往往静默，直到财务问报表为何跑了两遍。