cron1小时执行一次的表达式：写法、原理与常见误区

字段含义：为什么小时字段不能随便填

标准cron表达式由五个字段组成，依次是分钟、小时、日、月、星期。每个字段接受的取值不同：分钟字段覆盖一个小时的各个分钟位，小时字段覆盖一天中的各个小时位，日字段覆盖一个月中的各天，月字段覆盖十二个月，星期字段覆盖一周中的各天。

当某个字段写成星号时，表示该字段的“每一个取值”都会被匹配。因此把小时字段写成星号，意味着一天里的每个小时都命中；如果分钟字段也写成星号，那么每个小时里的每一分钟都会命中，触发频率就变成每分钟一次，而不是每小时一次。这就是新手最容易踩的坑：把“每小时”误解为“小时字段放星号即可”。

真正表达“每小时执行一次”，需要让分钟字段固定在一个确定的值上，而小时字段保持星号。这样每个小时只有那一个分钟位会命中，一天内命中的次数正好等于小时的数量。至于这个固定值取多少，取决于你希望任务在整点后的第几分钟启动。

触发原理：调度器如何判断“该不该跑”

cron调度器通常按分钟粒度推进。它维护一个“当前时间”的游标，在每一分钟到达时，把当前时间的各个部分与表达式中的字段逐一比对：分钟是否匹配、小时是否匹配、日是否匹配、月是否匹配、星期是否匹配。只有全部字段都匹配，任务才会被触发。

正因为比对是逐字段进行的，字段之间是“与”的关系，而不是“或”的关系。这解释了一个常见疑问：为什么把分钟和小时都写成星号会变得非常频繁，因为两个字段都放宽了匹配条件，命中的时间点数量是两者命中数量的乘积。

另一个需要理解的点是，cron并不记录“距离上次执行过了多久”，它只判断“当前这一分钟是否落在规则描述的时间集合里”。因此“每隔一段时间执行”并不是cron的原生语义，而是通过固定分钟位来间接实现的。如果调度器在某一分钟因为宕机或阻塞没有执行，cron通常不会在恢复后补跑那些错过的时间点，除非调度器本身提供了补偿机制。

实际写法：整点触发与错峰触发

最常见的写法是把分钟字段设为某个固定值，小时字段设为星号。这样任务会在每个小时的同一个分钟位被触发，形成稳定的小时级节奏。

如果希望任务在每个整点开始执行，就把分钟字段设为表示整点的那个值。整点触发的好处是时间点整齐，便于与日志、报表、对账等按小时切分的流程对齐；缺点是整点是系统负载的高峰，很多任务都会挤在同一时刻启动，容易造成资源争抢。

如果希望避开高峰，可以把分钟字段设为一个非整点的值，让任务在整点之后稍晚一点启动，从而与其他任务错峰。错峰的具体偏移量应结合任务自身耗时和上下游依赖来定，不宜过晚，否则可能影响下一个小时的执行窗口。

还有一种情况是任务只需要在部分小时执行，例如只在工作时段内每小时跑一次。这时可以把小时字段写成列表或范围，分钟字段仍然固定，从而把触发限制在指定的时间区间内。列表和范围的写法在不同调度器里基本一致，但要注意范围是否包含端点，以及是否允许跨零点书写。

注意事项：时区、夏令时与漏跑排查

第一，时区。cron表达式本身通常不携带时区信息，实际触发时刻由运行调度器的机器或调度服务所配置的时区决定。同一份表达式在时区不同的环境中，触发时刻可能相差若干个小时。跨地域部署时，应确认调度器的时区设置，必要时在表达式之外显式指定时区。

第二，夏令时。在实行夏令时的地区，时钟会在特定日期前后向前或向后调整。向前调整时，某些本地时间点可能不存在；向后调整时，某些本地时间点可能出现两次。对于按小时触发的任务，这可能导致某一天多跑一次或少跑一次。对时间精度要求高的任务，应改用不受本地时钟跳变影响的时区来调度。

第三，漏跑排查。如果发现任务没有按预期触发，先确认分钟字段是否被误设为星号或误设为多个值，再确认小时字段是否被意外限制。其次检查调度器进程是否存活、任务是否因为上一次执行尚未结束而被跳过。很多调度器对同一任务默认不允许并发执行，上一次没跑完，这一次就会被丢弃。最后检查日志中的触发记录与表达式是否一致，避免表达式被其他配置覆盖。

跨调度器的差异与迁移建议

不同调度器对cron的支持并不完全一致。有的只支持五个字段，有的额外支持秒字段或年份字段；有的支持步长、列表、范围的组合，有的对特殊字符的支持有限；有的把星期字段的取值定义为从零开始，有的从一开始。迁移表达式时，这些差异都可能导致触发时刻发生变化。

此外，部分调度器提供了非cron的扩展语法，例如用自然语言描述间隔，或提供专门的“每隔多久”配置项。这类写法可读性更好，但可移植性较差。如果表达式需要在多个平台之间复用，建议坚持使用标准的五字段形式，并在迁移后通过日志验证实际触发时刻是否符合预期。

对于需要精确间隔而非整点对齐的场景，可以评估是否改用调度器提供的间隔触发能力，而不是强行用cron模拟。理解工具的能力边界，往往比记住某个具体写法更重要。

常见问题