cron表达式1点半执行：写法、场景与常见误区

先搞清楚分钟和小时谁在前

cron表达式从左到右依次是分钟、小时、日、月、星期。想让任务在一点半执行，分钟位写 30，小时位写 1，后面用通配符占位即可。很多人习惯先说“一点”，就把 1 写在最前面，结果变成了每小时的第一分钟触发，和预期完全对不上。

写的时候还要注意小时字段的取值习惯。多数实现用 0 到 23 表示一天，凌晨一点就是 1；也有少数环境接受其他写法，但跨平台迁移时最好保持最通用的形式。分钟位写 30 没有歧义，前导零可加可不加，关键是别把两个数字的位置弄反。

如果你不确定自己的表达式是否写对，可以借助 Cron表达式 工具做一次对照解析，看看它实际会在哪些时间点触发。

每天一点半触发，适合放在哪些任务上

这个时间点通常落在业务低峰期，适合做那些不希望和白天请求抢资源的活儿。比如每天汇总前一天的订单数据、清理过期的临时文件、重建搜索索引、给运营团队推送日报。把这类任务安排在凌晨一点半，既避开了用户活跃时段，也给前一天的收尾工作留出了缓冲。

不过低峰期不等于没有依赖。如果任务需要读取前一天的数据，要确认上游的落库或归档已经完成；如果任务会写数据库，最好评估一下锁表和备份窗口是否冲突。时间点选得再合适，依赖没理顺照样会失败。

时区和夏令时，比表达式本身更容易出错

表达式写对了，任务却没在本地时间一点半跑，问题往往出在时区上。服务器、容器、调度平台各自可能使用不同的时区设置，表达式里的 1 代表的是调度器所在时区的一点，不是你以为的本地时间。跨区域部署时，先确认调度器用的是 UTC 还是本地时区，再决定小时位写几。

夏令时是另一个隐蔽的坑。在实行夏令时的地区，时钟拨动的那一天，凌晨一点半可能不存在，也可能出现两次。多数调度器对不存在的时刻会跳过或顺延，对重复的时刻只执行一次，但不同实现的行为并不一致。涉及对时间敏感的业务，最好在切换日前后观察任务的实际触发记录。

任务没按时跑，按这个顺序排查

先看表达式本身：分钟位是不是写成了 1、小时位是不是写成了 30，这种位置颠倒是最常见的错误。再看调度器日志里有没有解析失败的记录，有些平台对字段数量或特殊字符比较严格，多一个空格都会导致整条表达式无效。

表达式没问题，就查时区和系统时间。容器里跑的任务尤其容易忽略这一点，宿主机和容器的时间设置可能并不一致。最后看任务是否被并发策略拦住：上一次执行还没结束，下一次触发被跳过，表现上就像任务没跑。把这几层依次排除，大多数“一点半没执行”的问题都能定位到原因。

相关文章

• cron表达式1点半怎么写？避开整点陷阱

  解析cron表达式1点半的常见写法与误区，说明如何准确表达凌晨一点半，并分享定时任务中的实用技巧。

• cron表达式1点触发每5分钟更新一次怎么写？

  解析cron表达式1点触发每5分钟更新一次的两种含义，说明字段写法、持续范围与避坑方法。

• cron表达式1小时执行一次：从困惑到精通的实用解析

  详解cron表达式1小时执行一次的写法、常见误区与验证方法，帮助开发者准确配置每小时任务调度。

• cron表达式1小时一次：为什么你的定时任务没按预期跑

  从实际场景出发，解释每小时执行一次的cron表达式写法、常见误区与排查方法，帮助开发者避免定时任务配置错误。

• cron表达式1分钟执行一次，写法与常见误区

  讲清 cron 每分钟触发的字段写法、适用场景与常见误区，帮助开发者正确安排高频定时任务。

常见问题