脚本路径和执行权限是crontab静默失败的两大基础坑：必须用绝对路径（如/opt/backup/mysql_backup.sh）调用脚本，且需chmod +x赋予可执行权限；脚本内命令、配置及日志路径也须绝对化，并确保执行用户对所有资源有对应读写权限。
脚本路径和执行权限是 crontab 定时任务静默失败最常踩的两个基础坑。它们不报错、不提示，只让任务“看起来在跑”，实则什么都没做。
脚本必须用绝对路径调用
crontab 不会自动查找你的脚本，它只认完整路径。写 backup.sh 或 ./backup.sh，cron 默认在 root 用户家目录（/root）或空路径下找，十有八九找不到。
- 正确写法：直接用
/opt/backup/mysql_backup.sh这类完整路径 - 确认真实路径：运行
realpath backup.sh或which backup.sh，别靠记忆或 tab 补全 - 即使脚本和 crontab 属于同一用户，也不能省略路径
脚本文件本身要有可执行权限
crontab 不会解释脚本内容，它只当它是「可执行文件」来调用。没有 x 权限，脚本压根不会启动——crontab -l 能看见任务，/var/log/cron 显示“executed”，但里面 print、touch 全无反应。
- 加执行权：
chmod +x /opt/backup/mysql_backup.sh - 检查权限：
ls -l /opt/backup/mysql_backup.sh，确保显示-rwxr-xr-x或至少当前用户有x - Python 脚本也一样：哪怕用
python3 script.py方式调用，脚本本身最好也有+x，避免混淆
脚本内部命令和路径也要绝对化
脚本能启动，不代表它能跑完。内部调用的 mysqldump、rsync、tar，或读写的 config.json、logs/，都可能因环境不同而失效。
- 命令用绝对路径：
/usr/bin/mysqldump、/bin/tar，别只写mysqldump - 查真实位置：
which mysqldump或find /usr -name mysqldump 2>/dev/null - 开头就切工作目录：
cd /opt/backup || exit 1，再用相对路径才安全；否则所有路径都建议写绝对路径，比如/backup/logs/
权限与执行用户要严格匹配
谁的 crontab，就以谁的身份运行。root 的任务用 root 权限执行，普通用户任务默认用该用户身份运行。权限错位会导致数据库连不上、配置文件读不到、日志写不进目录等静默失败。
- 确认脚本归属：
ls -l /opt/backup/mysql_backup.sh，确保执行用户有读+执行权限 - 若用
~/.my.cnf存数据库密码，该文件必须属于对应用户，且权限为600 - 避免在脚本里用
sudo或交互式密码输入——cron 不支持等待
