shell脚本在crontab中执行失败主因是环境变量丢失或路径不规范，因cron使用极简环境（path仅/usr/bin:/bin，不加载用户配置），需用绝对路径、显式设置环境变量、重定向日志并模拟真实环境调试。
Shell脚本在crontab中执行失败，八成是环境变量丢失或路径写法不规范导致的。cron启动时用的是极简环境，不加载你的.zshrc、.bash_profile，PATH窄得只剩/usr/bin:/bin，HOME、LANG、PYTHONPATH这些全靠猜——结果就是命令找不到、路径错乱、日志空转、故障难定位。
确认cron是否真触发了任务
别急着改脚本，先看任务有没有跑起来：
- 查系统日志：
sudo grep CRON /var/log/syslog（Ubuntu/Debian）或sudo grep cron /var/log/messages（CentOS/RHEL），找对应时间点的调度记录 - 加一行测试任务：
* * * * * date >> /tmp/cron-check.log 2>&1，等一分钟看文件有没有更新 - 注意语法差异：用户级
crontab -e里没有用户名字段；系统级/etc/crontab必须带用户名，写错会静默忽略
模拟cron真实环境复现问题
你在终端能跑通，不代表cron能跑通。它默认用/bin/sh，PATH只有两个目录，也不设HOME：
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 手动模拟：
env -i PATH=/usr/bin:/bin /bin/sh -c 'which python3'，如果报“not found”，就说明环境确实不对 - 所有命令必须用绝对路径：运行
which python3、which jq、which node确认真实位置，别写python3或node - 脚本开头加
#!/usr/bin/env bash并chmod +x，但更稳妥的是在crontab里明确调用：/bin/bash /home/user/script.sh
脚本内统一管理环境与路径
把环境设置和主逻辑封装进一个shell脚本，比在crontab里堆export更清晰、易调试、可复用：
- 脚本开头显式设置关键变量：
export PATH="/usr/local/bin:/usr/bin:/bin:/home/user/.local/bin"、export HOME="/home/user"、export LANG="en_US.UTF-8" - 切到脚本所在目录：
cd "$(dirname "$0")" || exit 1，避免相对路径失效 - 日志重定向写全：
>> ./logs/run.log 2>&1，别漏掉2>&1，否则错误输出直接丢弃 - 加
set -u检查未定义变量，加set -x打印执行过程（调试期用，上线前关掉）
日志与权限必须双保险
没有日志，等于没执行；没有权限，等于没写完：
- 每条crontab命令末尾都加日志重定向：
0 3 * * * /home/user/backup.sh >> /home/user/backup.log 2>&1 - 确保脚本有执行权限：
chmod +x /home/user/scripts/job.sh - 检查shebang是否干净：用
head -n1 job.sh | cat -A看有没有BOM或空格；换行符必须是LF，不是CRLF - 避免交互依赖：含
sudo、ssh、gpg等需TTY的操作，在cron里大概率卡住或失败
