crontab执行时环境变量与交互式终端不同，需显式设置PATH、HOME等变量，使用绝对路径，指定Python解释器全路径，并正确处理日志重定向和系统级crontab用户字段。
crontab 执行时 PATH 和 SHELL 与交互式终端完全不同
你写的脚本在终端能跑，放进 crontab 就报 command not found，大概率是环境变量没对上。cron 启动的 shell 默认是 /bin/sh，PATH 通常只有 /usr/bin:/bin，不包含 /usr/local/bin、~/.local/bin 或你用 conda / pyenv 配的路径。
实操建议：
- 在 crontab 条目开头显式声明环境变量，比如：
PATH=/usr/local/bin:/usr/bin:/bin HOME=/home/username - 避免依赖
~展开，全部用绝对路径，HOME必须设，否则~/.bashrc或~/.profile中的配置根本不会加载 - 不要指望
source ~/.bashrc在 cron 里生效——/bin/sh不认source，得写成.（点号），且仅当 shell 是 bash 时才可靠
Python 脚本找不到模块？很可能是 virtualenv 或 pip install --user 没生效
你在终端用 pip install --user requests 或 pip install -e . 装的包，在 cron 里 import 就报 ModuleNotFoundError。因为 PYTHONPATH、sys.path 和用户 site-packages 路径都依赖于登录 shell 的初始化流程，而 cron 绕过了它。
实操建议：
- 用
which python查清你实际想调用的解释器路径，然后在 crontab 里写死，比如：/home/user/.pyenv/versions/3.11.5/bin/python /home/user/script.py - 如果用了 virtualenv，直接调用
venv/bin/python，别依赖激活脚本——cron 不执行activate - 临时调试时，在脚本开头加几行日志：
import sys; print(sys.executable, sys.path)，把输出重定向到文件，比猜快得多
crontab 日志没输出？stderr 默认被丢弃，stdout 不一定写进文件
你以为加了 > /tmp/cron.log 2>&1 就万事大吉，结果日志空空如也。常见原因：重定向符号被 cron 当作字面量处理（尤其含 % 时）、目标目录权限不对、或者脚本本身没触发任何输出。
实操建议：
- 所有
%字符必须转义为\%，否则 cron 会把它当时间字段解析，导致命令截断或报错bad minute - 重定向前先确保目录可写：
mkdir -p /tmp/logs && chmod 755 /tmp/logs - 更稳妥的日志方式是用
logger命令，比如：your_command 2>&1 | logger -t myscript，这样日志进/var/log/syslog，不受文件权限影响
系统级 crontab（/etc/crontab）和用户 crontab 行为不一致
你在 /etc/crontab 里写了 * * * * * user script.sh，但脚本就是不执行；而用 crontab -e 写的同一行却正常。区别在于：系统级 crontab 要求**显式指定运行用户**，而用户级 crontab 隐含当前用户。
实操建议：
- 系统级 crontab 格式固定为：
minute hour dom month dow user command，漏掉user字段就会静默失败 - 用户 crontab（
crontab -e）格式是：minute hour dom month dow command，没有 user 字段 - 优先用用户级 crontab，除非真需要以 root 或其他用户身份运行；改完
/etc/crontab必须用sudo systemctl reload cron（或crond）生效，不是改完就自动重载
最常被忽略的是：cron 环境里连 ls 都可能不是你熟悉的那个——它可能是 busybox 版本，不支持 --color 或 -h。别假设任何命令行为，查 which、看 $PATH、打日志，比翻文档快。
