crontab 定时任务写法速查：五个字段与常见坑

发布时间:2026-10-10 13:17

## 五个字段怎么读 格式为"分 时 日 月 周"五个字段，空格分隔，星号代表任意值。每天凌晨三点写作 0 3 * * *，每十分钟一次写作星号斜杠 10 星号 星号 星号，每周一早上五点是 0 5 * * 1。周字段里 0 和 7 都算星期天，个别老发行版不认 7，统一写 0 最稳。日与周同时写死时，两者取并集而非交集，这一点与多数人的直觉相反，比如"每月 1 号且周一"实际是"每月 1 号或每个周一都执行"，频率直接翻倍，造出这种任务往往要等数据出问题才被发现。 ## 环境变量差异 cron 的执行环境远比登录 shell 干净：PATH 通常只有几条系统路径，语言、时区变量也可能不同，脚本里能用的命令换到 cron 里就找不到。对策有三条：任务里一律写命令的绝对路径，用 which 提前确认；需要的变量在 crontab 文件顶部显式声明；复杂逻辑不要塞成一行，写成独立脚本，crontab 只负责按时调用脚本。"手动跑正常，定时跑就失败"的问题，绝大多数落在这条上，排查时先模拟 cron 环境执行一遍。 ## 百分号要转义 百分号在 crontab 里有特殊含义：第一处被解释为换行，其余部分被当作该命令的标准输入。date 命令的格式串里全是百分号，必须逐个转义。典型的备份日志命名写法： ```bash 30 2 * * * /opt/scripts/dump.sh > /backup/db_$(date +\%F).log 2>&1 ``` 同样的脚本放进独立脚本文件里调用则无需转义，这也是推荐脚本化的另一个理由。 ## 日志落盘与排查 每条任务都把标准输出与错误一并重定向到日志文件，否则出错时没有任何线索可查。排查顺序建议固定：先看系统的 cron 日志，确认任务有没有被调度；再翻任务自己的日志，看卡在哪一步；最后以 cron 的最小环境手动执行复现。多任务之间把时间错开几分钟，避免凌晨同一分钟集中抢磁盘 IO。在顺云的云服务器上跑备份、清理类任务时，配合控制台的资源监控观察任务时段的负载，长期能看出该不该调整时间点。