set -e 仅对直接命令生效，管道、逻辑运算符等会绕过；应显式检查退出码、配合 set -o pipefail、函数内单独启用，并用 trap 'echo "ERROR at ${BASH_SOURCE[0]}:${LINENO}"' ERR 定位错误。
bash 脚本里 set -e 为什么经常不生效
它只对“直接执行的命令”起作用，管道、逻辑运算符、子 shell 和函数调用都会绕过。比如 cmd1 | cmd2 中 cmd1 失败，整个管道仍返回 0；foo && bar 里 foo 失败，bar 根本不执行，但 set -e 不报错。
真正可靠的做法是显式检查退出码：
- 用
if ! cmd; then echo "fail"; exit 1; fi替代裸写cmd - 管道出错时改用
set -o pipefail（必须和set -e同时用） - 函数内部也要单独加
set -e，因为函数默认不继承父 shell 的选项 - 避免在
while、until条件中依赖命令失败来退出循环——它们本就靠退出码判断，set -e在这里反而干扰逻辑
调试时怎么快速定位哪一行出错了
光靠 set -x 打印所有命令太吵，尤其有循环或长管道时。更有效的是结合 BASH_SOURCE 和 LINENO 做条件输出。
常见错误现象：脚本某处静默失败，日志没线索，set -x 输出滚动太快抓不住上下文。
实操建议：
- 临时加一句
trap 'echo "ERROR at ${BASH_SOURCE[0]}:${LINENO}"' ERR，出错立刻打印位置 - 想看变量值？别反复
echo $var，用declare -p var防止空格/换行截断 -
set -x开启后，用set +x关闭局部段落，比如只打开可疑函数 - 注意
$?是上一条命令的退出码，但会被echo、test等覆盖，需要立即保存：rc=$?; [ $rc -ne 0 ] && echo "failed: $rc"
捕获信号和清理资源为什么总漏掉 SIGHUP
交互式终端断开时发的是 SIGHUP，不是 SIGINT 或 SIGTERM。很多脚本只 trap INT TERM QUIT，结果后台运行时被 nohup 或 ssh 断连干掉，临时文件、锁、子进程全留着。
使用场景：部署脚本、长期运行的监控任务、带 exec 替换进程的守护逻辑。
关键点：
- 必须显式列出
HUP：trap cleanup HUP INT TERM，不能靠trap cleanup 0（它只管正常退出） -
cleanup函数里别用可能被中断的命令，比如rm -rf /tmp/myapp.*应该先find /tmp -name 'myapp.*' -delete，避免通配符扩展失败 - 子进程默认继承父进程的 signal mask，如果用了
nohup或disown，得确保子进程自己也处理SIGHUP，否则 cleanup 不触发 - 注意
trap不捕获SIGKILL和SIGSTOP，这两个信号无法被忽略或拦截
变量未定义导致脚本行为诡异怎么办
set -u 是最直接的解法，但它会把 ${var:-default} 这类安全展开也当错误。更稳妥的是分层防御。
性能影响几乎为零，但能提前暴露拼写错误、环境缺失、配置遗漏等问题。
实操建议：
- 全局加
set -u，但对允许为空的变量用${var:-}显式声明意图 - 读取配置文件时，用
source 比裸 <code>source config.env更安全，防止未声明变量污染环境 - 函数参数校验别只写
[ -z "$1" ]，要用[ -z "${1:-}" ]，否则传入空字符串时$1展开失败 - 数组变量容易踩坑：
${arr[@]}在空数组时展开为空，但${#arr[@]}才是真实长度，别用[ -n "${arr[@]}" ]判空
最容易被忽略的是子 shell 环境隔离——( set -u; echo $UNDEF ) 会报错，但 cmd | while read line; do echo $UNDEF; done 不会，因为 while 是子 shell，set -u 不跨进程生效。
