crontab执行失败主因是环境隔离、路径错误和日志缺失：默认PATH极简、不加载shell配置、工作目录为/，需在crontab顶部显式声明SHELL、PATH、HOME，脚本内全用绝对路径，确保执行权限并重定向日志。
crontab 执行环境和终端完全不一样
你手动运行 python3 backup.py 没问题，但加进 crontab 就报 command not found 或 ModuleNotFoundError——这不是脚本写错了，是 cron 根本没加载你的 shell 环境。
- 默认只设了极简
PATH=/usr/bin:/bin，pip3、python3、git等可能在/usr/local/bin或虚拟环境里，直接找不到 -
$HOME、$USER、~展开失败，~/.config类路径全失效 - 不读
~/.bashrc、/etc/profile，所以 alias、export 的变量统统丢失
解决方法：在 crontab 文件顶部显式声明（不是在脚本里）：
# 编辑任务：crontab -e SHELL=/bin/bash PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin HOME=/home/your_username 0 2 * * * /home/user/scripts/backup.sh
相对路径在 cron 里等于“不存在”
你在终端里 cd ~/scripts && ./run.sh 跑得好好的，但 cron 启动时工作目录是 /，所以 ./data.log → /./data.log，当然打不开。
- 脚本里所有文件路径（输入、输出、配置）、命令调用（如
mysql -h...）、甚至cd都必须用绝对路径 - 别信
~，它不会自动展开；$HOME在未设置HOME=...前也为空 - 日志路径写成
/var/log/backup.log，别写./log/backup.log
权限、日志、执行权三连错
任务“静默失败”最常见原因不是语法错，而是根本没跑起来。
-
chmod +x your_script.sh必做——cron 不会帮你解释脚本，只认可执行位 - 脚本里用到的文件/目录（比如数据库备份要写入的
/backup/），所属用户必须对 cron 运行用户（如root或你的用户名）有写权限 - 不加日志重定向 = 自断线索：
0 2 * * * /path/to/script.sh >> /var/log/backup.log 2>&1，否则 stdout/stderr 全丢给 cron 邮件系统（通常没人查）
注释格式错一个空格就让整行失效
crontab 对格式极其敏感，尤其注释。
- 只有行首
#才是注释，* * * * * /cmd.sh # 这是注释→ cron 会把#当作命令参数，直接报错跳过 - 注释行前不能有空格、tab、不可见字符，否则被当成非法语法，整个 crontab 加载失败
- 验证方式：执行
crontab -l，如果看到你的任务没列出来，或提示bad minute，八成是某行注释或空格惹的祸
真正麻烦的不是“怎么写对”，而是“为什么看起来对却没执行”——环境隔离、路径盲区、静默丢日志，这三点叠加，足以让一个定时任务在生产环境躺平三天没人发现。
