Bash脚本避坑：别让默认设置毁了你的生产环境

没写过生产环境脚本的人很难体会，Bash 默认的“宽容”其实是最大的陷阱。它最离谱的地方在于：即便前面的命令执行失败了，它依然会像没事人一样继续往下跑。

在公司推行自动化部署的时候，我见过最典型的惨剧就是：脚本里写了 cd /tmp/deploy 紧接着一个 rm -rf *。结果因为某个原因 cd 失败了，脚本没报错停止，直接在根目录或者家目录下执行了删除命令。这种“沉默的失败”在运维实战中简直是噩梦。

想让 Bash 变得像个正常的编程语言，至少得在脚本开头加上这行配置：

set -euo pipefail

这几个参数的实际作用是：

• -e (errexit)： 任何命令执行失败（返回非零值）立刻退出，别再往下跑了。
• -u (nounset)： 引用了没定义的变量直接报错。这能救命，避免因为变量名写错导致 rm -rf /$FOLDER 变成 rm -rf /。
• -o pipefail： 解决管道命令的漏洞。默认情况下，cat file | grep pattern 只要 grep 成功了，即便 cat 报错，整个管道也被认为是成功的。开启这个后，只要管道中任何一环断了，整个命令就返回失败。

如果你的团队还在写那种靠“运气”运行的 Shell 脚本，建议强制要求把这行写进所有部署脚本的模板里。虽然 set -e 也有一些边缘情况比较复杂，但总比在凌晨三点面对被删库的生产环境要好得多。