crontab依赖后台服务crond运行，配置语法严格且环境变量受限，需确保crond启动、使用绝对路径、正确设置path/shell、避免日期与星期冲突，并启用cron日志便于调试。
crontab 不是“写完就跑”的命令，它依赖后台服务 crond 运行，且配置语法容错极低——少一个空格、路径没写绝对路径、环境变量缺失，任务就会静默失败。
crond 服务必须先启动，否则 crontab 任何配置都无效
很多用户执行 crontab -e 成功保存后，发现命令根本没执行，第一反应是语法错了，其实根本原因是 crond 没在运行。
-
/sbin/service crond status查看状态，常见返回是inactive (dead) - 启动命令：
/sbin/service crond start（CentOS/RHEL 系统）或systemctl start cron（Ubuntu/Debian） - 开机自启：
chkconfig crond on（旧版）或systemctl enable cron（新版） - 注意：
crond和cron是不同名称，取决于发行版；但进程名统一为crond或cron，可用ps aux | grep crond确认
crontab -e 编辑时，PATH 和 SHELL 与你终端不一致
你在 shell 里能直接敲 php test.php，但放进 crontab 就报 command not found，因为 cron 默认只认 /bin:/usr/bin，且不读取你的 ~/.bashrc。
- 要么用绝对路径：把
php换成/usr/bin/php（用which php查） - 要么在 crontab 文件顶部显式声明：
SHELL=/bin/bash和PATH=/usr/local/bin:/usr/bin:/bin - 避免在命令中使用
~，一律写成/home/username/或$HOME（但需确认 shell 支持） - 调试技巧：加日志重定向，例如
* * * * * /usr/bin/php /path/to/script.php >> /tmp/cron.log 2>&1
时间字段顺序和星期/日期的冲突陷阱
很多人想“每周一早上9点执行”，写成 0 9 * * 1，结果发现每月1号也执行了——因为 cron 的规则是：当 day-of-month 和 day-of-week **任一条件满足**，任务就触发（不是“且”关系）。
- 正确做法：把不需要触发的日子设为
*，另一项设具体值；如只按星期跑，就写0 9 * * 1，同时把day-of-month留*（别填数字） - 更安全写法：用
0 9 * * 1 [ $(date +\%d) -eq 01 ] || /path/to/cmd做二次判断（不推荐，复杂化） - 星期可写
mon、sun，但注意大小写敏感，且部分系统只认数字（0=周日，6=周六） - 通配符
*表示“每”，,表示枚举（如1,3,5），-表示范围（如1-5），/表示步长（如*/10表示每10分钟）
用户级 vs 系统级 crontab 配置位置完全不同
你用 crontab -e 编的是用户级任务，存于 /var/spool/cron/username；而 /etc/crontab 是系统级配置，格式多一列 user 字段。
- 用户级：
crontab -e→ 不带用户名字段，第六列直接是命令；root 用它管理自己任务最常用 - 系统级：
/etc/crontab或/etc/cron.d/myjob→ 格式是min hr dom mon dow user command，必须指定执行用户（如root或www-data） - 不要直接编辑
/var/spool/cron/xxx文件，要用crontab -e，否则 cron 可能不重载 - 权限控制靠
/etc/cron.allow和/etc/cron.deny：若cron.allow存在，则只有其中列出的用户能用 crontab
真正容易被忽略的是：cron 日志默认不开启，出问题时连“是否触发过”都难确认。建议在 /etc/rsyslog.conf 中取消注释 cron.* 行，重启 rsyslog，再查 /var/log/cron —— 这比反复猜语法靠谱得多。
