Cron 表达式在线解析
解析 5 段与 6 段 Cron 表达式，给出中文含义与未来 10 次执行时间，附常用模板与字段含义说明。
定时任务没按预期执行时，第一个要确认的就是表达式本身写对没有：是 5 段还是 6 段、*/5 落在哪个字段、星期天该写 0 还是 7，这些细节光看文档很容易混淆，写成 2 月 31 日这种永不触发的组合也不容易发现。
输入表达式后立即给出中文语义描述与未来 10 次触发时间，把抽象字段翻译成「每天 9 点 30 分」这类可以核对的句子，再对照执行时间列表，大部分写法错误都能当场发现。计算使用浏览器本地时间，表达式不会发往服务器，附带的常用模板与字段说明表可以随时查。
5 段与 6 段写法的差异
标准 crontab 是 5 段——分、时、日、月、周；Quartz、Spring 以及部分云厂商的调度服务会在最前面多一个秒字段，共 6 段。同一串字符在两种规则下含义完全不同，字段数写错会得到完全不同的触发频率。另外星期字段中 0 和 7 都表示周日；日与周同时被限制时，多数实现按「或」的关系处理，而不是「与」。
步长、列表与区间的语义
*/5 表示从字段起点开始每 5 个单位执行一次，所以分钟位上的 */5 是每小时的第 0、5、10 分；写成 5/10 才是「从 5 开始每隔 10」，两者不等价。逗号表示列表，如 1,15,30；连字符表示区间，如 9-17；区间后面还能加步长，如 10-20/2。要小心自相矛盾的写法：0 0 31 2 * 指 2 月 31 日，永远没有触发时间。
时区与执行环境带来的偏差
Cron 按运行环境的本地时区计算：容器默认多为 UTC，于是「每天 0 点」在北京时间实际是早上 8 点，这是定时任务时间偏移最常见的来源，夏令时切换当天还会出现某次任务被跳过或执行两次。另外 cron 执行时的环境变量很少，PATH 通常只有 /usr/bin:/bin，脚本里用到的命令建议写绝对路径，输出也重定向到日志，否则报错只会进邮件。
常见问题
- Cron 表达式 5 段和 6 段有什么区别？
- 5 段是「分 时 日 月 周」，对应 Linux crontab；6 段在最前面加了秒，常见于 Quartz、Spring 和云厂商的调度服务。同一串字符在两种规则下含义不同，先确认目标平台用哪种规则，再写表达式。
- 为什么我的定时任务没有执行？
- 先确认平台是 5 段还是 6 段，再看日与周是否同时被限制、有没有写成 2 月 31 日这类永不触发的组合，最后检查时区——容器里的 UTC 会让执行时间整体偏移 8 小时。任务自身报错、被上一次执行锁住或进程没启动也要一并排查。
- */5 和 0/5 是一样的吗？
- 在分钟位上结果相同，都是从 0 开始每 5 分钟。区别出现在其他字段：*/5 在「日」位表示从 1 号开始每 5 天，即 1、6、11、16、21、26、31 号；写成 0/5 的含义依实现而定，通常等同于 */5，建议统一用 */n 避免歧义。
- Cron 按哪个时区执行？
- 按执行环境（服务器或容器）的本地时区，不是你浏览器所在时区。容器一般使用 UTC，所以凌晨的任务会落在北京时间早上 8 点。可以设置 TZ 环境变量或把时区写进调度配置；本工具的预览按你本机时区计算，核对前先把两边时区对齐。