shell脚本执行失败多因环境、权限、路径或解释器问题，需依次检查：可执行权限、shebang正确性（含换行符与bom）、报错上下文、变量与路径引用规范及运行时上下文。
Shell脚本执行失败，多数情况不是语法“写错了”，而是环境、权限、路径或解释器细节没对上。排查时别急着重写，先盯住几个关键点。
检查脚本是否具备可执行权限
Linux不会因为文件后缀是 .sh 就自动执行它。必须有 x 权限：
- 运行 ls -l script.sh 查看权限，若没有 x（如显示 -rw-r--r--），就无法直接 ./script.sh
- 加上权限： chmod +x script.sh
- 或者不依赖权限，改用解释器显式运行：bash script.sh 或 sh script.sh
确认第一行 shebang 是否正确且存在
脚本开头的 #!/bin/bash（或 #!/usr/bin/env bash）不是注释，它决定了用哪个解释器执行。常见问题：
- 路径写错，比如写成 #!/bin/sh 却用了 [[ ]] 或 source 的高级特性（/bin/sh 在很多系统里是 dash，不兼容 bash 扩展）
- 换行符是 Windows 风格（CRLF），导致解释器路径末尾带 ^M，报错类似 /bin/bash^M: bad interpreter。用 dos2unix script.sh 或 sed -i 's/\r$//' script.sh 修复
- 脚本保存为 UTF-8 with BOM，BOM 字节干扰 shebang 解析。用编辑器另存为 “UTF-8 no BOM” 或用 vim 输入 :set nobomb 后保存
定位报错行和实际错误类型
别只看最后一行报错，要结合输出上下文判断：
- 命令未找到（command not found）：检查命令拼写、是否在 $PATH 中，或加绝对路径（如用 /usr/bin/curl 而非 curl）
- 语法错误（syntax error near unexpected token）：常见于引号不配对、if 缺 fi、for 缺 done，或变量展开时没加双引号导致空格截断
- 权限拒绝（Permission denied）：可能是目标文件/目录不可写，或脚本尝试以普通用户身份操作需 root 的资源
- 直接静默失败：加 set -u（报未定义变量）、set -e（出错立即退出）、set -x（打印每条执行命令）辅助调试，例如开头加：#!/bin/bash\nset -euo pipefail
验证变量、路径和当前工作目录
脚本行为高度依赖运行上下文：
- 用 pwd 和 echo $0 确认当前路径和脚本自身位置；相对路径（如 ./data/file.txt）可能因执行位置不同而失效
- 变量未引号包裹易出问题：比如 cp $SRC $DST，当 $SRC 含空格时会拆成多个参数。应写作 cp "$SRC" "$DST"
- 环境变量在非登录 shell 中可能缺失（如 ~/.bashrc 里的自定义变量），脚本中不要默认它们已加载，必要时显式 source 或赋值
