Cron君工具合集

cron每分钟表达式：写对五个星号位，任务才按时跑

更新于

cron每分钟表达式指的是让计划任务在每个整分钟都触发一次的那条时间规则，通常写成五个星号字段。它看似简单，却是很多调度配置的起点：有人用它做心跳检测，有人拿它跑临时轮询，也有人写完之后发现任务根本没按预期执行。读者最关心的无非三件事——这串符号到底代表什么、放在不同环境里是否一致、以及为什么明明写了每分钟却出现漏跑或重叠。下面从实际使用中的困惑切入，把含义、写法与注意点讲清楚。

五个星号位到底在说什么

标准 cron 的时间行由五个位置组成，依次对应分、时、日、月、星期。每个位置填一个星号，含义是“该位置取任意值”，五个位置全取任意值，合起来就是每个小时里的每一分钟都命中一次。理解这一点很关键：星号不是“每秒”的意思，cron 的最小调度粒度到分钟，所以这条规则的实际节奏是每分钟触发一回，而不是持续不断地跑。

有人会问，星期和日期两个位置同时写星号会不会冲突。在多数实现里，这两个字段是“或”的关系，但两边都是通配时结果依然是每分钟，不会因此变成别的频率。真正需要注意的反而是字段数量：有些环境在五段之外还接受秒级字段，写成六段，顺序和含义都变了。把五段规则直接粘进六段格式的配置里，往往就是任务行为异常的源头。

为什么写了每分钟却像没跑

调度器不会替你记住上一次执行到哪一步。如果上一轮任务还没结束，下一分钟又到了，不同系统的处理方式并不统一：有的直接跳过本次触发，有的会排队等待，还有的允许并发执行。于是同一个表达式，在轻量任务上看起来一切正常，换成耗时操作就可能出现堆积。排查时先看任务本身要跑多久，再看调度器对重叠的策略，比反复改表达式更有效。

另一类“像没跑”的情况来自环境差异。容器里的 cron 服务可能压根没启动，或者时区与预期不一致，导致触发时刻整体偏移。还有的部署方式把配置写在镜像里，更新后没有重新加载，规则改了却仍在跑旧版本。这些都不是表达式语法的问题，却常被误判成写法错误。动手改符号之前，先确认调度进程在运行、配置已生效、时区设置明确，能省下不少来回。

每分钟触发适合放在哪些场景

高频轮询是它最自然的用途：检查某个队列是否有新消息、确认某个外部接口是否恢复、把内存里的计数定期落到存储中。这类动作单次开销小，对时间精度要求不高，晚个几十秒通常无伤大雅，用每分钟一次的节奏刚好。

反过来，涉及大量数据扫描、外部调用限流严格、或者需要严格顺序的任务，就不适合直接套用这个频率。更稳妥的做法是把触发和执行分开：调度只负责投递一个标记，由后台工作进程按自身能力消费。这样即使某一分钟触发密集，也不会把压力直接压到业务逻辑上。还有一点容易忽略——日志。高频任务产生的记录增长很快，若不做轮转或采样，磁盘和检索成本会悄悄上升，这跟表达式本身无关，却是长期运行必须面对的现实。

改写与验证的几个习惯

写完规则别急着上线，先在测试环境观察几轮触发记录。很多调度工具会展示最近若干次预计执行时刻，对照它确认分钟位是否真的每分钟命中，比盯着符号空想可靠。若发现触发间隔忽长忽短，优先怀疑任务耗时与重叠策略，而不是表达式。

修改已有规则时，保留旧配置一段时间再切换，方便对比行为差异。对关键任务，可以在任务内部记录开始与结束时间，用日志判断是否出现堆积。另外，把规则和它的用途写在同一处注释里，过几个月再回看时，能快速想起当初为什么选这个频率。表达式本身很短，真正难维护的是它背后的意图。

总结

cron每分钟表达式由五个通配字段组成，含义是每个整分钟触发一次，粒度止于分钟。写对它不难，难的是处理重叠执行、环境时区与配置生效这些外围因素。把任务耗时、调度策略和日志增长一并考虑，再配合测试环境的触发记录验证，才能让高频调度稳定运行。

相关文章

常见问题

Q1五个星号就是每秒执行一次吗？

不是。cron 的调度粒度到分钟，五个星号表示每个整分钟触发一次，两次触发之间至少间隔一分钟，不会在一分钟内连续运行。

Q2为什么任务有时跳过某一分钟？

常见原因是上一轮还没结束，调度器按重叠策略跳过了本次触发；也可能是调度进程未运行、配置未重新加载或时区设置不一致，需要逐项排查。

Q3这条规则在六段格式里能直接复制吗？

不能直接照搬。六段格式通常多出一个秒级字段，字段顺序和含义都变了，把五段规则粘进去会导致触发时机与预期不符，需要按目标格式调整。

Q4每分钟触发会不会给系统带来压力？

取决于任务本身的耗时与资源占用。轻量检查通常影响有限；耗时操作容易造成堆积，建议把触发与执行分离，由工作进程控制实际并发。