Linux cron脚本执行失败主因是环境差异：PATH缺失致命令找不到，需用绝对路径或显式设置；工作目录非预期，应cd到脚本目录或用绝对路径；Shell不一致（默认/bin/sh）导致bash语法报错，须匹配shebang或指定SHELL；输出未重定向致错误静默，应重定向日志并启用set -e/-x。
Linux计划任务（cron）中脚本执行失败，绝大多数情况不是脚本本身有bug，而是执行环境与手动运行时完全不同——缺少环境变量、路径不一致、权限受限、Shell差异等都会导致看似正常的脚本在crontab里静默失败。
PATH环境变量缺失是最常见原因
cron默认只使用极简的PATH（通常是/usr/bin:/bin），不会加载用户的~/.bashrc、/etc/profile等配置。如果脚本里调用了python3、jq、mysqldump等非基础命令，而它们不在默认PATH中，就会报“command not found”。
- 用
which 命令查出完整路径，脚本中直接写绝对路径（如/usr/local/bin/python3） - 在crontab开头显式设置PATH：
PATH=/usr/local/bin:/usr/bin:/bin - 或在脚本开头用
source /etc/profile && source ~/.bashrc（不推荐，依赖交互式Shell且可能出错）
当前工作目录不是你预期的目录
cron执行脚本时，工作目录是用户家目录（如/home/user），而非脚本所在目录。若脚本里用了相对路径读取配置文件或写日志（如./config.ini或>> output.log），就会找不到文件或写到错误位置。
- 脚本开头加
cd "$(dirname "$0")"切换到脚本所在目录 - 所有路径尽量用绝对路径，或基于
$(dirname "$0")构造（如$(dirname "$0")/config.ini） - 避免依赖当前目录的命令，例如
ls *.log应改为ls /var/log/myapp/*.log
Shell解释器不一致引发语法错误
crontab默认使用/bin/sh（在多数发行版中是dash），而非你的登录Shell（如bash）。如果你的脚本第一行是#!/bin/bash，但crontab里写的是sh /path/to/script.sh，那bash特有语法（如[[ ]]、source、数组、$(( ))）会直接报错。
- 确保crontab调用方式匹配脚本shebang：用
/path/to/script.sh（可执行权限+shebang），而非sh /path/to/script.sh - 检查脚本是否有bash-only特性，临时改用POSIX兼容语法测试（如
[ ]代替[[ ]]） - 可在crontab中指定Shell：
SHELL=/bin/bash（全局）或bash /path/to/script.sh（单行）
没有标准输出/错误重定向，失败悄无声息
cron默认把stdout和stderr发邮件给任务所属用户（若本地mail服务未启用，则直接丢弃）。这意味着脚本崩溃、报错、echo调试信息全看不到，只能靠“没结果”被动怀疑。
- 强制重定向输出：
0 2 * * * /path/to/script.sh >> /var/log/myscript.log 2>&1 - 在脚本开头加
set -e（遇错退出）和set -x（打印执行命令），便于定位卡点 - 用
logger "script started"写系统日志，比文件日志更可靠（不受目录权限影响）
