主题
Cron 表达式解析
写了个 0 2 * * 1，想确认它到底是「每周一凌晨 2 点」还是别的。定时任务写错了不会报错，只会在你以为它跑的时候没跑——而这种问题往往过很久才被发现。
打开「Cron 表达式解析」看到的初始界面。在浏览器本地完成、数据不离开浏览器，免费。
五段分别是什么
┌─ 分钟 (0-59)
│ ┌─ 小时 (0-23)
│ │ ┌─ 日 (1-31)
│ │ │ ┌─ 月 (1-12)
│ │ │ │ ┌─ 星期 (0-7，0 和 7 都是周日)
│ │ │ │ │
* * * * *工具会解析并预测最近几次的触发时间——这是验证的唯一可靠方式。凭读的判断经常出错，看实际触发时间不会。
最容易错的：日和星期同时指定
0 0 1 * 1 你以为是「每月 1 号且是周一」，实际多数实现是**「每月 1 号」或「每周一」——两个条件是或**的关系，不是且。
这条规则反直觉，也是 cron 事故的头号来源。要「每月 1 号」就把星期位留成 *，反之亦然。
几个常用写法
| 表达式 | 含义 |
|---|---|
*/5 * * * * | 每 5 分钟 |
0 * * * * | 每小时整点 |
0 2 * * * | 每天凌晨 2 点 |
0 2 * * 1 | 每周一凌晨 2 点 |
0 2 1 * * | 每月 1 号凌晨 2 点 |
30 9 * * 1-5 | 工作日早上 9:30 |
时区在哪定
Cron 表达式不带时区，用的是运行它那台机器的时区。
这是分布式部署的常见坑：本地写好的 0 2 * * *，部署到 UTC 时区的服务器上，实际会在北京时间上午 10 点跑。
部署前确认服务器时区，或者在任务里显式指定。
频率别定太密
*/1 * * * *（每分钟）这类高频任务，要考虑上一次还没跑完下一次就来了的情况。多数 cron 实现不会等待，会并发启动——任务如果操作同一份数据，就会互相踩踏。
需要防重入的话，任务自己要加锁，不能指望 cron。
每月只跑一次的任务，上线后手动跑一次
这条来自实际教训：0 6 1 * * 这种一个月才触发一次的任务，如果配置写错了，你要等一个月才知道。
上线后照着 cron 那行的命令手动跑一次，确认路径、权限、环境变量都对。
浏览器本地处理
不上传服务器。