Cron 表达式写错多半是这 4 件事：段数、日和周、时区、下次执行时间

本地工具箱 · 使用指南 · 2026-11-04 · 建议落地路径 /guide/cron-expression-pitfalls/

定时任务最让人不踏实的不是不跑，而是「跑是跑了，但跑的时间和想的不一样」。备份脚本写成了每小时一次，报表在凌晨三点发出去，或者本该工作日执行的任务周末也跑了一轮。0 9 * * 1-5 这串符号看着短，能踩的坑不少。

上线前值得按下面四条过一遍。

一、先数段数：5 段、6 段、7 段不是一回事

Linux crontab 用的是 5 段：分、时、日、月、周。Quartz、Spring 的调度表达式会在前面加秒、后面加年，变成 6 段或 7 段，字段含义和取值范围都跟着变。

最常见的错就是把 6 段表达式粘进 crontab：本意是「每天 9 点」，因为首位多了个秒字段，整串被往后错一位，结果完全不同。反过来，把 5 段喂给 Quartz，也可能被按秒解释。

所以看到表达式第一件事是数空格：5 个字段就当 crontab，6/7 个字段先确认调度框架。别只看它长得像不像。

标准 cron 里，当日（第 3 段）和周（第 5 段）都不是 * 时，两者是或关系：日期匹配或星期匹配，都会触发。

比如想写「每月 1 号且是工作日」，写成 0 9 1 * 1-5 并不会得到这个结果——它会在每月 1 号执行一次，并且在每周一到周五各执行一次。很多人是在核对执行次数时才发现多跑了好几轮。

这类规则靠脑子推容易漏，最好让工具把接下来几次执行时间列出来，一眼看有没有多出来的日期。

crontab 按服务器本地时间跑，云主机、容器常常默认 UTC。业务方说的「每天上午 9 点」一般是北京时间，中间差 8 小时。容器里没配 TZ、CI 平台按 UTC 调度，都会造成这个偏差。

排查时把三件事分开记：表达式写的是哪个时区、调度进程实际用什么时区、你用来核对「下次执行时间」的设备是什么时区。三者不一致，再正确的表达式也会看起来不对。

一句人话含义（比如「每周一至周五 9:00」）能确认你写对了意图，接下来几次具体时间能确认边界行为：跨月、跨年、月末、夏令时切换，都藏在这几行里。

尤其要验这几种写法：

本地工具箱的 Cron 表达式解析正好按这个思路做：粘一条表达式，实时给出一句人话含义、每个字段的取值说明，以及接下来 10 次执行时间。

几个针对上面四条的细节：

顺带一提，站点里时间戳转换和时区转换可以配合着用：前者确认日志里的触发时刻，后者把 UTC 与北京时间并列对照，夏令时会自动换算。查跨时区调度问题时，这两个页面比手算靠谱。

第 4 步别省。多数「表达式没写错但跑歪了」的问题，都是在这里露出来的。

问：日和周都写了，工具会按哪个算？ 按标准 cron 的或关系处理，两者任一匹配就执行。核对「接下来 10 次」能直接看出来有没有多跑。

问：6 段和 7 段怎么切换？ 页面支持 5 段 crontab 与 Quartz / Spring 的 6、7 段互相切换，切换后字段含义会跟着调整。

问：cron 能识别法定节假日吗？ 不能。cron 只认星期和日期，遇到调休、放假要由业务代码或调度平台额外判断。

问：表达式会上传到服务器吗？ 不会，这个页面全程在浏览器本地计算。站点里只有明确标注「需上传」的付费 AI 功能才会把内容提交到后端。

问：手机上能查吗？ 页面是响应式布局，工具面板在手机上自动变上下两栏；每个工具有独立地址，可以单独收藏。

段数、日和周、时区、下次执行时间——按顺序过一遍，绝大多数定时任务的配置错误都能在上线前拦住。把 Cron 表达式解析收进收藏夹，写完表达式粘进去看一眼那 10 行时间，比上线后翻日志省心；不用注册，打开即用。

需要直接打开工具？前往本地工具箱首页，66 个工具免注册使用；本页提到的每个功能都有独立地址，可单独收藏。