生产环境写 Bash 脚本千万别信默认设置，建议强制开启 set -euo pipefail
我之前在公司推行自动化部署时，见过一个非常典型的惨剧。有个脚本逻辑是先 cd /tmp/deploy 进入部署目录，紧接着执行 rm -rf * 清理旧文件。结果在一次部署中，因为权限问题或目录丢失，cd 命令执行失败了。但 Bash 并没有因为失败而停止，而是直接在当前的根目录或用户家目录下执行了删除操作。这种“沉默的失败”在实战中简直是运维噩梦。
要想让 Bash 变得像一个严谨的编程语言，而不是靠运气运行的指令集，我建议在所有生产脚本的开头强制加上这行配置：
set -euo pipefail这行代码虽然短，但它通过三个参数彻底改变了 Bash 的运行机制。
首先是 -e（即 errexit）。它的作用是：只要任何一个命令执行失败（返回非零值），脚本立刻退出，不再往下跑。如果没有这个设置，你的脚本可能会在一个已经崩溃的环境中继续执行后续的配置，导致产生一堆难以排查的次生故障。
其次是 -u（即 nounset）。这个参数能救命。在 Bash 中，如果你引用了一个没有定义的变量，默认情况下它会被视为空字符串。想象一下，如果你写了 rm -rf /$FOLDER，而 $FOLDER 因为拼写错误没被定义，那么这条命令在实际执行时就变成了 rm -rf /。开启 -u 后，只要引用了未定义的变量，Bash 会直接报错并停止，强迫你检查变量定义。
最后是 -o pipefail。这是很多资深开发者也会忽略的细节。在默认模式下，管道命令的退出状态只取决于最后一个命令。比如执行 cat non_existent_file | grep "pattern"，即便 cat 因为文件不存在而报错，但只要 grep 没找到匹配项（返回 1）或者找到了（返回 0），整个管道的最终状态可能依然被认为是“成功”的。开启 pipefail 后，只要管道中任何一环断了，整个命令链条都会返回失败。
当然，set -e 并不是万能药，它在处理一些预期内会失败的命令时（比如用 grep 检查文件是否存在）会导致脚本意外退出。这时候你可以通过 command || true 或者使用 if 语句来局部覆盖这个行为。
但总的来说，在凌晨三点面对被误删的生产环境时，你会发现这种“严苛”的配置比任何事都重要。如果你的团队还在写那种缺乏容错机制的 Shell 脚本，建议直接把这行配置写进所有部署脚本的模板里。
