cron表达式100分钟该怎么配置
这个说法通常表示：任务启动后，希望它按照一个跨越小时边界的固定分钟间隔持续执行。读者最关心的往往不是字段怎么填写，而是普通 Cron 能否保持间隔稳定、服务重启后如何续跑，以及怎样避免日历匹配造成执行间距变化。
在线工具Cron表达式
为什么常见 Cron 写法会偏离预期
Cron 更像一张“日历条件表”，而不是持续计时器。分钟、小时、日期等字段分别匹配当前时间，满足条件时才触发任务。分钟字段进入下一个小时后会重新从该小时的起点计算，因此，直接填写步进规则，通常只能表达“每个小时内部按某个步长命中”，不能自然延续为跨小时的固定间隔。
这也是最容易踩坑的地方：配置看起来像间隔执行，实际却可能在小时交界处缩短等待时间。若目标间隔还会跨越日期边界，单靠字段组合就更难维持连续节奏。
先判断你要的是间隔还是时刻
可以先问自己一个问题：任务应该在固定钟点运行，还是以上次执行时间为基准再次触发？
- 如果业务关心早晚、工作日或特定日期，Cron 很合适，因为它擅长描述日历时刻。
- 如果业务要求每次运行之间保持相同等待长度，更适合使用应用内调度器、延迟队列或系统计时服务。
- 如果任务执行耗时不稳定，还要区分固定频率与固定延迟。前者按计划时间推进，可能发生并发；后者会等本次完成后再开始等待，节奏更稳妥。
确认属于日历触发后，可以用校验Cron字段与触发时间检查配置，重点观察小时交界和日期切换附近的结果，而不要只看局部时间段。
可落地的几种实现方式
应用长期运行时，可由调度框架保存下一次执行时间。任务完成后，根据预定间隔计算新的触发点，并把状态写入持久化存储。这样即使进程重启，也能判断是补执行、跳过，还是从当前时刻重新排期。
已有消息队列的系统，可以通过延迟消息串联任务：消费完成后再投递下一次消息。这样便于控制重试，但必须配合幂等标识，防止网络抖动或重复投递造成业务重复。
若部署环境提供系统级计时器，也可让它负责间隔触发和故障恢复。相比拼接复杂的 Cron 时刻列表，这种方案更贴近“经过一段时长再运行”的真实需求，维护者也更容易理解。
必须使用 Cron 时怎样降低风险
受限于托管平台时，可以把一天内的目标时刻预先展开，再写成若干日历规则。不过这种方式本质上是时刻枚举，不是连续间隔。跨日衔接、时区变化和规则修改都可能改变间距，配置也会逐渐难读。
落地前应检查几个问题：平台采用哪个时区；错过触发后是否补跑；任务重叠时是跳过、排队还是并行；失败重试会不会与下一轮同时发生。对关键任务，还应记录计划触发时间、实际开始时间和执行结果。这样出现偏移时，能够判断问题来自调度规则、运行环境还是任务本身。
总结
普通 Cron 适合匹配日历时刻，不擅长表达跨小时延续的固定间隔。强调稳定间距时，优先考虑应用调度、延迟队列或系统计时器；受平台限制只能使用 Cron 时，应验证跨小时、跨日、时区、重试与并发行为。
相关文章
- cron表达式100天后执行为何不能直接写
解析cron表达式100天后执行的实现边界，并说明绝对日期、延迟队列与到期扫描的选择方法。
- cron表达式10：数字背后的调度含义
解读cron表达式中数字10的常见含义，涵盖分钟、小时、日期等字段，并提醒字段顺序与平台差异，帮助避免调度误配。
- cron表达式1到底表示什么，别先猜周期
解释 Cron 表达式中数字一的真实含义、字段位置差异、方言兼容问题及排错方法。
- cron表达式0秒：含义、写法与常见误区
解释cron表达式中秒位写零的含义，说明其与分钟级调度的区别，并提醒字段顺序等常见误区。
- cron表达式0点：定时任务在午夜触发的写法与避坑
解析cron表达式0点的含义、常见写法与调试技巧，帮助开发者准确配置午夜定时任务，避免时区与日期字段的常见错误。
常见问题
Q1为什么不能直接在分钟字段里写步进值？
因为分钟字段会随着小时切换重新匹配。它表达的是每个小时内符合条件的分钟位置，并不会记住上一次执行后已经过去多久。
Q2能否把多个 Cron 规则拼在一起？
可以枚举目标时刻，但得到的是近似的日历计划。规则数量增多后，跨日衔接、时区调整和人工维护都容易出错，更适合计划固定且变动较少的场景。
Q3固定频率和固定延迟有什么区别？
固定频率按预定时间轴触发，任务执行过久时可能重叠；固定延迟则在本次任务结束后再等待一段时间，更适合禁止并发的处理流程。
Q4服务重启后怎样继续原来的节奏？
应持久化上次完成时间或下次计划时间，并提前定义恢复策略。重启后可根据业务要求选择补跑、跳过过期任务，或从当前时间重新开始。