linux cron表达式必须严格遵循5字段空格分隔格式，从左到右依次为：分钟（0–59）、小时（0–23）、日（1–31）、月（1–12）、星期几（0–7），其中“日”与“星期几”是“或”关系；步进语法（如/5）仅在支持该范围的字段中有效，星期几字段不支持步进；cron环境极简，需用绝对路径、显式设置path和shell，并重定向输出排查问题；安全测试应先用 验证日志，再收紧表达式，修改后立即生效。
Linux 的 cron 表达式不是“写出来就行”，它必须严格匹配 5 字段空格分隔格式，且每个字段的取值范围、特殊符号行为、环境变量缺失都可能让任务静默失败。
crontab 里这 5 个字段分别代表什么
顺序固定，不可交换，从左到右依次是：
分钟（0–59）小时（0–23）-
日（1–31）— 注意：和day of week是“或”关系，任一满足即触发（常被误以为是“且”） 月（1–12）星期几（0–7，0 和 7 都表示周日）
例如 30 2 * * 1 表示“每周一凌晨 2:30 执行”，但 30 2 1 * 1 表示“每月 1 号 或 每周一”的凌晨 2:30 各执行一次——这点极易导致重复运行。
常见错误：* /5 这类步进写法在哪些位置有效
/ 步进语法只在支持该范围的字段中合法，且不能脱离基础范围使用：
- ✅
*/5 * * * *：每 5 分钟（分钟字段允许 0–59，/5 合理） - ✅
0 */2 * * *：每两小时整点（小时字段 0–23，/2 合理） - ❌
* * */5 * *：不是“每 5 天”，而是“每月第 5、10、15…30 日”，但若当月没有 30 日，最后那次不会补到下月 —— 它不跨月计算 - ❌
* * * * */5：语法错误！星期几字段不支持步进（cron实现差异大，多数版本直接忽略或报错）
想实现“每 5 天运行一次”，得用脚本判断日期差，cron 本身不提供此能力。
为什么脚本在 crontab 里不执行，但在终端能跑
根本原因是 cron 使用极简环境：PATH 通常只有 /usr/bin:/bin，无用户 profile，无 shell 函数，且工作目录是用户 home。
- 用绝对路径写命令：把
python script.py改成/usr/bin/python3 /home/user/script.py - 显式设置必要环境变量：在 crontab 开头加
SHELL=/bin/bash、PATH=/usr/local/bin:/usr/bin:/bin - 重定向输出排查问题：
*/10 * * * * /path/to/cmd >> /tmp/cron.log 2>&1 - 避免依赖交互式 shell 特性（如
source ~/.bashrc或别名），cron 不加载这些
如何安全测试新写的 cron 表达式
不要等明天才看效果。用 systemd-run 或手动模拟是最靠谱的验证方式：
- 临时触发一次：运行
systemd-run --on-calendar="2024-06-15 14:30:00" --scope -- bash -c 'your_command'（需 systemd 环境） - 用在线工具仅作语法初筛（如 crontab.guru），但它无法反映你的 PATH、权限、shell 差异
- 最稳妥的是：先写成
* * * * *，确认日志能打出，再逐步收紧时间表达式 - 注意：修改
crontab -e后无需重启服务，但旧进程不会自动 reload —— 新增条目立即生效，已运行中的任务不受影响
真正难的从来不是写出一个“看起来对”的表达式，而是确保它在无人值守时，在正确的环境、正确的路径、正确的权限下，按你脑中设想的逻辑跑起来 —— 而不是靠猜日志在哪、PATH 是啥、或者某天突然多跑了一次。
