启用 set -euo pipefail 可让脚本在命令失败或变量未定义时立即终止，暴露80%低级错误；配合 strace、$? 检查、stderr 调试日志及合理 trap 清理，大幅提升可调试性与健壮性。
用 set -e 和 set -u 让脚本自动失败而不是硬扛
脚本静默跳过错误、变量未定义却继续执行——这是最隐蔽的调试噩梦。set -e 让任何命令非零退出时立即终止，set -u 在引用未声明变量时报错，两者合用能暴露 80% 的低级疏漏。
- 加在脚本开头：直接写
set -euo pipefail（pipefail确保管道中任一环节失败都算整体失败） - 别在交互式 shell 里全局启用，它会干扰日常命令；只在脚本内启用
- 临时绕过某行：用
command || true或set +e配合set -e恢复，但要加注释说明原因 -
set -u下${var:-default}是安全的，但$var直接引用未定义变量会炸
定位「命令没执行」的真实原因：检查 $? 和 strace
看到脚本卡住或结果不对，第一反应不该是重跑，而是确认上一条命令到底有没有成功、有没有被信号中断、甚至有没有被 alias 劫持。
- 紧接关键命令后加
echo "exit code: $?"，比猜快十倍 - 怀疑命令行为异常？用
strace -f -e trace=execve,openat,read,write <code>your_script.sh看它实际调了啥系统调用 -
which和type -a必须查两遍：which ls可能返回 alias，type -a ls才显示 alias / function / binary 优先级 - 注意子 shell 影响：
(cd /tmp; pwd)里的cd失败不会影响外层，$?也捕获不到
日志和调试输出别混在一起：用 exec 重定向 stderr 到文件
把调试信息 echo 到 stdout，结果被管道吞掉或和正常输出搅成一团——这是日志设计最常翻车的地方。真正的调试输出必须走 stderr，且最好单独落盘。
- 开头加
exec 2> /tmp/script-debug.log，所有echo "debug: xxx"默认进文件（记得加2>&1如果要用echo写 stderr） - 不要用
echo "msg" >> debug.log多次打开文件，竞态下可能丢行；exec一次重定向更稳 - 生产环境关调试？把
exec 2>/dev/NULL放条件分支里，别删代码 - 时间戳很重要：用
echo "$(date '+%T') debug: xxx" >&2，不然多行日志分不清先后
处理信号和中断：trap 不是摆设，但别乱用 EXIT
脚本被 Ctrl+C 杀掉后残留临时文件、锁没释放、进程没清理——不是“运气不好”，是没认真对待信号。
-
trap 'rm -f /tmp/mylock' int TERM比trap 'rm -f /tmp/mylock' EXIT更可靠，因为EXIT在set -e中断时不触发 -
trap后面的命令要写完整路径（如/bin/rm），避免依赖$PATH或被 alias 干扰 - 调试时加
trap 'echo "TRAPPED: $?"' ERR，能快速发现哪行悄无声息失败了 - 别在
trap里调用复杂函数或外部命令，超时或死锁会让整个清理流程卡住
真正难的不是写 trap，是想清楚哪些资源必须清理、哪些信号必须捕获、哪些清理动作本身不能失败——这些细节不画流程图很容易漏