根本原因是脚本无执行权限或含Windows换行符（CRLF），导致/bin/bash解析失败；同时PATH环境变量与终端不同、工作目录默认为/root、stderr未捕获也会引发各类静默失败。
脚本在宝塔面板里执行报错“Permission denied”或直接无输出
根本原因通常是脚本没有可执行权限，或者用了 Windows 换行符（CRLF）导致 /bin/bash 解析失败。宝塔计划任务默认以 root 用户调用 /bin/bash 执行脚本，但不会自动加 chmod +x，也不会处理换行符兼容性。
实操建议：
- 上传脚本后，先在终端手动运行
chmod +x /path/to/your/script.sh - 用
file /path/to/your/script.sh检查换行符：若输出含CRLF，说明是 Windows 格式；应改用LF - 在宝塔文件管理器中编辑保存时，默认会转为
LF；但用外部编辑器（如 VS Code、Notepad++）上传前务必设为 Unix（LF）换行 - 计划任务命令栏里不要写
sh script.sh，直接填绝对路径：/bin/bash /www/wwwroot/script.sh（更稳妥）或/www/wwwroot/script.sh（前提是已chmod +x）
脚本里调用的命令找不到（如 curl、php、mysqldump）
宝塔计划任务运行环境的 $PATH 和你登录终端时不同，很多命令不在默认搜索路径中，尤其是宝塔自建的 PHP 或 MySQL 路径（如 /www/server/php/82/bin/php）。
实操建议：
- 不用
php xxx.php，改用绝对路径，例如：/www/server/php/82/bin/php /www/wwwroot/test.php - 在脚本开头加
#!/bin/bash，并在第一行后立即导出完整 PATH：export PATH="/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin" - 如果依赖宝塔安装的软件，先用
which php或ls -l /www/server/php/*/bin/php确认实际路径 - 测试时可在脚本末尾加
env > /tmp/env.log，执行后查看/tmp/env.log确认 PATH 是否符合预期
脚本执行成功但没达到预期效果（比如数据库没备份、文件没生成）
常见于路径错误、用户权限隔离、工作目录不明确。宝塔计划任务默认工作目录是 /root，不是脚本所在目录，也不是网站根目录；且脚本内所有相对路径都会基于 /root 解析。
实操建议：
- 脚本开头强制切换工作目录：
cd /www/wwwroot/myapp || exit 1 - 所有文件路径写绝对路径，避免
./backup.sql这类写法；日志路径也一样，例如：/www/wwwroot/myapp/logs/backup_$(date +%F).log - 检查目标目录是否对
root用户可写（尤其当脚本由宝塔触发，但目录属主是www时） - 在脚本中重定向 stderr，例如：
mysqldump ... > /backup/db.sql 2>> /var/log/backup.err，方便定位静默失败
日志为空或只显示“started”，看不出具体哪步挂了
宝塔计划任务自带的日志只记录任务启停和退出码，不捕获 stdout/stderr —— 这是最大盲区。很多“执行成功”其实只是 shell 进程启动了，脚本内部早已崩溃。
实操建议：
- 务必在脚本末尾加
echo "[$(date)] script finished" >> /var/log/myscript.log，确认是否真跑完 - 每段关键逻辑后加简单日志，例如：
echo "[$(date)] dumping database..." >> /var/log/myscript.log - 用
set -e开头让脚本遇到任何命令失败立即退出，避免错误被忽略 - 临时调试时，在宝塔任务命令栏里把脚本改成：
/bin/bash -x /www/wwwroot/script.sh >> /tmp/debug.log 2>&1，-x会打印每条执行命令
换行符和权限是进门第一关，PATH 和工作目录是第二层陷阱，而缺失 stderr 捕获会让问题彻底隐形。别信“执行成功”的状态栏，日志里没看到你写的那句 echo，就不算真正跑通。
