写Bash脚本这么多年，我印象最深的不是哪条语法多巧妙，而是脚本在没人注意的地方悄悄出错、还装成一切正常的样子。你猜怎么着？一台测试机上，定时任务把旧临时目录清掉了，但真正要更新的数据根本没生成，监控还是一片绿——因为脚本最后一条命令echo "done"返回了0。这种"过程失败但结果成功"的假象，恰好是Google 风格强调防御性编程要解决的痛点。
Google 风格里对 Bash 脚本的定位一直很明确：能不用Shell就不用Shell，一旦用了，就要按工程化的方式把错误处理、变量检查、可调试性做扎实。落到具体操作上，就是我们常说的防御性编程。这篇我不打算给你讲Bash语法大全，只把我实践Google风格Bash脚本时反复用到的防御手段拆开讲清楚：每一招解决什么问题、为什么这样设计、在真实项目里会踩到哪些坑。适合写部署脚本、CI脚本、数据处理脚本的工程师参考，也适合刚接触Shell想少走弯路的同学。
1. Bash默认行为为何自带事故体质
1.1 命令失败后脚本依然会继续往下走
Bash脚本本质是一条一条命令按顺序执行。问题在于，除了最后一条命令的退出码，前面的命令返回什么，脚本引擎并不关心。例如：
cd /opt/myapp/current rm -rf ./data/cache如果cd失败，脚本并不会停，rm会在当前目录下继续执行。假设当前目录恰好是/etc/，后果就不是一句"脚本报错"能带过去的事故。更常见的情况是变量拼写错误，导致cd到一个空字符串路径，rm同样会落在登录用户当前所在目录。
我第一次被这类问题教训，是在一台构建机上。脚本里写了rm -rf "$BUILD_OUTPUT/"，BUILD_OUTPUT这个变量在那个环境里没被导出，展开后整条命令差点变成rm -rf /。最终它被系统权限拦住了，但那一瞬间后背发凉。从那之后，凡是涉及删除、覆盖、cd的命令，我默认都不信任裸写的方式，必须先确认前置路径和变量状态。这不是强迫症，这是事故换回来的直觉。
1.2 未定义变量默认是空字符串
Bash默认把未定义变量当成空字符串处理。这个特性从交互式Shell一路继承过来，对命令行用户很友好，但对脚本却非常危险。if [ "$token" = "secret" ]里的token没定义时，条件不会报错，只是不成立；真正危险的是rm、mv这类命令，变量为空时命令可能作用于目录本身，或者变成清除命令的根路径。
set -u就是针对这一点的补丁。打开之后，只要脚本试图展开一个没定义的变量，Bash会直接报"unbound variable"并终止。注意在Bash 4.4之前，set -u和空参数列表之间存在经典bug，所以如果你还在维护老版本Bash环境的脚本，尽量把可选参数写成"${1:-}"这种带安全默认值的形式，别让set -u本身成为新的故障源。
1.3 管道默认只看最后一段的退出码
管道可能是Bash里最容易被忽视的错误点。管道返回的执行状态是最后一个进程的退出码，前面的命令就算炸了，只要后边的命令成功，整条管道依然返回0。举一个典型场景：
mysqldump mydb 2>backup.err | gzip > backup.sql.gzmysqldump把表结构导到一半，数据库连接断开，它输出了错误并返回非0，但gzip正常收到前面的数据流（很可能不完整），仍然打包成功，整条命令返回0。脚本继续往下执行，后面不管是上传备份还是通知同事备份完成，都在拿一份损坏的产物当真。这是管道给防御性编程出的最大考题，也是为什么pipefail几乎是所有工程化Bash脚本的标配。
2. set -Eeuo pipefail：第一道必须入场的大门
2.1 set -e决定脚本是否立即失败
set -e（等价于set -o errexit）表示脚本中的任何一条简单命令返回非0退出码时，立即终止。它的主要作用是防止"继续执行造成二次破坏"。但set -e不是万能的，它有一组设计上的例外：出现在if、while、until条件表达式里的命令，即使返回非0也不会终止脚本；被!取反的命令；由&&或||连接的命令列表的左侧命令，同样不受set -e管辖。
这意味着什么？如果你写：
grep "pattern" file.txt && process_linegrep返回1（没有匹配）时，脚本不会退出，而是继续往下执行。这在某些场景合理，在某些场景却会掩盖错误。我的建议是，不要把希望全押在set -e上，重要的命令要显式处理退出码，set -e只是兜底，不是挡箭牌。
2.2 set -u：把"变量没定义"变成可见错误
set -u的行为我在1.2已经提过，这里重点说它和参数传递的结合。打开set -u之后：
set -u rm -rf "${1}/temp" # 如果没传参数，脚本直接退出如果你希望第一个参数允许为空，应该写"${1:-}"。还有一个小细节：打开set -u后，如果一个数组变量在使用时被"部分展开"而本身又没赋值完整，也可能触发unbound variable报错，所以处理数组前务必把数组赋值完整，别偷懒用空数组先占位。
2.3 set -o pipefail：让管道忠诚地回报任何一个失败
pipefail会在管道中某个命令非0退出时，让整条管道返回该命令的退出码，而不是最后一条命令的。注意：如果管道里有多个命令失败，返回的是最右边那个非0退出码，不是第一个。这个细节偶尔会误导排查方向，看到报错行号时，记得往管道右侧找。
管道为什么非要这个选项？因为真实场景里几乎没有"前面的命令失败了，后面还要继续喂数据"的设计。我习惯把任何涉及过滤、压缩、解密的命令行都放进pipefail保护之下。同时要注意另一个反向问题：如果某些命令（比如head、less）会主动截断前面的数据流，pipefail反而可能让脚本在SIGPIPE上退出，这时可以用|| true显式声明"这一环允许截断失败"，并加注释说清楚原因。
2.4 写在shebang后面的标准位置
比较标准的开头是这样：
#!/usr/bin/env bash set -Eeuo pipefail-E是让ERR trap在函数内和命令替换中也生效，后面讲trap时会用到。这四个选项的顺序没有硬性要求，但必须写在函数定义和主逻辑之前，因为它们只对设置之后的代码生效。有人喜欢用set -o errexit这种长格式，清晰但比短格式费手指，我的习惯是短格式加一行注释说明每个字母的意图，团队Review时一眼能看懂。
提示：想要把set -Eeuo pipefail作为团队默认，最好在脚手架模板里直接固定，而不是靠每个人每次手敲。漏一个字母，防御力度就少一大截。
3. 变量与路径：防御性编程最容易被忽视的第二战场
3.1 ${parameter:-word}全家桶
对于需要用未定义或空变量提供默认值的场景，Bash提供了四兄弟：${var:-default}、${var:=default}、${var:?message}、${var:+alt}。它们的语义差异如下：
| 写法 | 变量未定义或为空时 | 变量有值且非空时 |
|---|---|---|
| ${var:-default} | 使用default，不修改变量本身 | 使用变量原值 |
| ${var:=default} | 使用default，并修改变量为default | 使用变量原值 |
| ${var:?message} | 输出错误信息并退出脚本 | 使用变量原值 |
| ${var:+alt} | 什么都不展开 | 使用alt替换原值 |
我在项目里的使用原则是：配置类变量用:-兜底，必填参数用:?显式报错，只在少数需要"第一次赋值后再重用它"的场合才用:=。这里提醒一句——不要把所有变量都套上默认值。set -u已经帮你拦住了"未定义"这一层，如果你再给每个未定义变量都安排默认值，拼写错误导致的空值就会被静默吞掉，反而更难排查。拿捏的尺度在于：这个变量被默认值影响后，会不会对安全或数据产生隐患。如果会，就列白名单做显式校验，而不是图省事套个默认值完事。
3.2 引号永远不要嫌多
Shell编程里最容易复现的经典事故，是文件路径里有空格。很多人写for file in $FILES，当FILES="a.txt b.txt"时，循环元素会被拆成两个；要是文件名本身叫"my report.pdf"，拆完就找不到文件。更微妙的是，不加引号的命令替换会先按IFS拆分，再对每个词做路径通配展开。也就是说，一个变量传进去，可能因为当前目录恰好有匹配的通配符文件，被展开成完全不同的参数列表，把你原本想传给程序的值偷梁换柱。
所以我在Review里对新人说得最多的一句话是：命令参数位置上的变量，默认都要加双引号。数组除外，数组要用"${arr[@]}"这种固定展开方式。引号是用户输入和命令执行之间最便宜的缓冲，不用白不用。
3.3 用数组代替空格分隔的字符串
Google 风格的脚本理念里，很少推荐用空格分隔字符串来保存多个文件。Bash 4以上的环境里，数组是更好用的容器：
files=() for path in /data/input/*.json; do files+=("$path") done printf '%s\n' "${files[@]}"这里有个边缘情况要注意：/data/input/*.json如果没有任何匹配，通配符会作为字面量字符串留在数组里，而不是展开成空数组。如果你预期"没有匹配也算一种正常结果"，先执行shopt -s nullglob，让不匹配的模式展开为空，这样后续处理才不会对着一个假路径瞎忙。
3.4 用readonly守住关键常量
脚本里总有一些不应该被覆盖的路径、版本号、密钥文件名。在变量前加readonly（或declare -r）可以防止后面某个函数意外给同名变量赋值。这个操作的收益很小，但成本也很小。比如：
readonly DEPLOY_ROOT="/srv/app" readonly REQUIRED_BASH_MAJOR=4一旦某个地方试图给DEPLOY_ROOT重新赋值，Bash会直接报错。工程底线就是靠这种一个个小约束垒起来的。
4. 函数层级的错误传递：return、local 与 trap 的组合拳
4.1 local声明和命令替换之间的隐蔽bug
这是我见过最隐蔽的set -e失效场景之一：
function update_config() { local result result=$(command_that_might_fail) echo "$result" }如果写成local result=$(command_that_might_fail)，你感觉这条命令失败时set -e会接管，但实际上不会。原因是Bash执行local时，不管右侧命令替换返回什么，都把local解释为一个成功的声明操作，返回0；右侧命令替换的失败状态被local吞掉了，result拿到空字符串，脚本继续跑。这是Google风格里反对在变量声明时做命令替换的原因之一。
正确的写法是：
local result result=$(command_that_might_fail)此时赋值语句的退出码等于命令替换的退出码，set -e才能真正生效。这个细节我写进过团队的Code Review规则，拉出来问一问，命中率极高。如果你在现网排查"为什么脚本在某个变量为空时还在跑"，优先检查是不是这个模式。
4.2 函数返回值要显式
Bash函数没有声明返回值类型这回事，return的数字就是函数级别的退出码。一个常见失误是：函数末尾的最后一条命令决定了返回值，如果它不是你想表达的状态，调用方拿到的就是误导信息。我见过一个函数，明明中间步骤失败了，但因为函数最后一行是echo一条提示信息，echo返回0，整个函数就被当成成功。
我的习惯是：函数内最后显式写return 0（成功）或return "$?"（透传失败），让调用方清楚知道函数认为自己在做什么。在函数入口做参数校验，失败时立刻return非0：
function publish_artifact() { if [[ $# -ne 1 ]]; then echo "usage: publish_artifact <path>" >&2 return 2 fi cp "$1" /srv/releases/ return "$?" }调用方这边，if publish_artifact "$file"; then ...; else ...; fi比无条件调用然后赌一切正常可靠得多。
4.3 把错误处理和退出统一封装
散落的echo "error"和exit 1不是好维护的结构。大家更常用的模式是写一个die函数：
function die() { echo "[FATAL] $*" >&2 exit 1 }再配合退出码参数和日志级别，可以满足绝大多数脚本需求。关键点在于：错误信息要写到STDERR，而不是STDOUT。如果错误信息混进STDOUT，被$(cmd)命令替换捕获，会因为错误文本污染后面的所有数据处理流程。这是细节，但往往就是这些细节决定脚本在线上能不能快速定位问题。
4.4 trap EXIT和trap ERR做最后一道保险
防御性编程不单要防"这一条命令失败"，还要防"失败之后环境没清理"。
tmpdir=$(mktemp -d) trap 'rm -rf "$tmpdir"' EXIT这样不管脚本正常结束还是提前退出，临时目录都会被清掉。trap ERR一般用来记录现场，比如：
set -Eeuo pipefail trap 'echo "line $LINENO failed with exit code $?"' ERR-E确保函数体、命令替换里的ERR也能被捕获。这里LINENO是Bash内置的当前行号，配合日志打点，线上排查的时候，比"不知道哪一行挂了"强一百倍。我一度以为set -e之外不需要ERR trap，直到一次凌晨被叫起来看告警，日志里只有一句"脚本失败"，却不知道在哪一行，那才叫痛苦。
5. 临时文件、后台任务与不可信输入：边界场景的防御
5.1 mktemp而不是手工拼临时路径
很多脚本爱用固定的/tmp/myapp_xxx.log或/tmp/build.out。问题在于：多个实例并发运行时文件互相覆盖；假设攻击者提前在/tmp/建了同名的symlink，程序会往他指定的文件里写内容，这就是经典的符号链接攻击。正确的姿势是用mktemp：
tmpfile=$(mktemp) tmpdir=$(mktemp -d)mktemp会在安全的临时目录里生成带随机后缀的路径，并且权限默认600/700。用完立即trap EXIT清理。我还会给mktemp加上模板，比如mktemp -d /tmp/myapp.XXXXXX，便于出问题时定位是哪个进程的残留。固定路径的临时文件，除了方便你自己，也会方便别人恶意利用，这个账要算清楚。
5.2 后台进程的wait返回值一定要接住
启动后台任务时，如果只启动不等待，脚本可能完全不知道子任务最终失败；如果启动后立即wait "$pid"，set -e会接管子进程的失败。还有一个容易漏掉的场景：wait的退出码是最后一个被等待子进程的退出码，如果有多个任务，建议逐个wait并记录结果：
pids=() cmd1 & pids+=("$!") cmd2 & pids+=("$!") for pid in "${pids[@]}"; do wait "$pid" done这里for循环里wait失败时，set -e会立即中断。如果希望失败后先收拢其他任务，再统一判断，就不要依赖set -e，而是手动累加每个wait的退出码，最后再决定整体是成功还是失败。
5.3 拒绝eval和不安全的动态执行
eval、source一个不确定来源的文件、根据用户输入直接拼SQL再交给数据库执行——这类设计在Bash脚本里尤其危险，因为它把字符串直接当成代码执行。Google风格里明确反对把动态内容拿来执行。像"根据输入的函数名调用对应函数"这种需求，不要用间接调用或运行时的函数名拼接，优先用case分发：
case "$mode" in start) do_start ;; stop) do_stop ;; *) die "unknown mode: $mode" ;; esaccase的匹配结果最多变成分支，不会直接变成字符串执行，这在可控性上完全不同。动态执行一时爽，等到输入里出现意外字符时，你面对的就是一个无法预测的脚本行为。
6. 一个可直接落地的Google风格脚本骨架
6.1 骨架结构与重点注释
我实际工程里经常用下面这个骨架。你直接复制改逻辑就行，它会帮你挡掉大部分常见事故：
#!/usr/bin/env bash # # deploy.sh - 部署产物到目标环境 # set -Eeuo pipefail readonly SCRIPT_NAME="$(basename "${BASH_SOURCE[0]}")" readonly TARGET_DIR="/srv/app/releases" function usage() { cat <<EOF usage: $SCRIPT_NAME <version> [--force] Deploy a given version to target directory. options: -h, --help show this help message -f, --force overwrite existing artifacts EOF } function die() { echo "[FATAL] $*" >&2 exit 1 } function cleanup() { rm -rf "${tmpdir:-}" } function main() { local version="${1:-}" local force=0 [[ -n "$version" ]] || die "version is required" tmpdir=$(mktemp -d) trap cleanup EXIT if [[ -n "${FORCE_FLAG:-}" ]]; then force=1 fi # 具体业务逻辑从这里开始 echo "deploying version $version to $TARGET_DIR" } main "$@"为什么用main()包住全部逻辑？因为脚本顶层的变量会影响后续所有代码，包进函数可以缩小变量作用域；把所有局部变量声明在main里，配合local，减少全局名字污染。trap EXIT里用了${tmpdir:-}，是为了防止tmpdir还没赋值脚本就退出时，cleanup不会因为空字符串而误删。这个细节我踩过一次：早期版本直接rm -rf "$tmpdir"，变量没赋值时它会尝试删除当前目录下的空路径，直接报错退出。
6.2 参数解析用getopts而不是手撸
短参数用getopts是标准做法。getopts会自动处理带值的参数、非法选项、选项顺序，比手撸$1/$2解析稳得多：
while getopts "hfv:" opt; do case "$opt" in h) usage; exit 0 ;; f) force=1 ;; v) version="$OPTARG" ;; *) usage; exit 1 ;; esac done shift $((OPTIND-1))注意选项定义字符串里v:表示-v后面必须跟值。Bash内置的getopts不支持长参数（--force这种），需要自己写case；如果你想支持长参数，可以加一个预处理循环，把--force转成-f。我的建议是：短参数能覆盖90%的场景，长参数不是必需品；如果一定要有，别图省事引入外部解析库，一个while加case足够。
6.3 用shellcheck做静态检查
Google风格的代码风格检查落到Bash上，shellcheck是目前事实标准。它能告诉你：这个地方没加引号可能导致word splitting；这里用了可能受PID变化影响的进程判断；这种写法在POSIX和Bash下有差异。维护脚本的团队建议把shellcheck接进pre-commit钩子或CI流程，早发现问题远比上线后炸掉便宜。
我在本地习惯是写完脚本先bash -n file.sh检查语法，再shellcheck -x file.sh，最后抽一两个不常见的输入（带空格路径、空参数）跑一遍。三步走完再敢往外发。严格来说，shellcheck不等于正确性，但它能帮你消灭大量低级问题，剩下的才是真正的业务逻辑风险。
7. 实践中我更推荐的取舍：别让防御变成累赘
7.1 什么时候要主动关掉set -e
防御性编程不是把选项全打开就完事。有些场景下就是要"即使其中一个失败了，也要尝试所有选项"，比如批量从多个镜像站拉包，或者收集一批清理任务的结果。这时有两条路：
set +e run_all_tasks set -e这种临时开关容易破坏状态，如果中间某段代码忘记恢复，后面整个脚本的防御就失效了。更推荐的做法是用if或|| true显式表达容错：
if ! run_task_optional "$task"; then echo "warning: task failed for $task, continue..." >&2 fiif方案的好处是，容错范围是局部的，set -e的全局保护仍然覆盖其他代码。类似地，管道里如果确实想忽略某个环节的失败，在该环节后面加|| true并加注释说明理由，比关掉整个pipefail清楚得多。
7.2 在可移植性和严格性之间拿捏
Bash版本差异是现实的坑。macOS自带的还是Bash 3.2，Linux发行版普遍是4.4以上。set -Eeuo pipefail、[[ ]]这些在Bash 3.2下有的能用，有的存在行为差异；关联数组更是要求Bash 4以上。如果你要维护一个跨macOS和Linux的脚本，最稳妥的做法是：
- 开头检测Bash版本，低于需要的最低版本就直接报错退出；
- 用
#!/usr/bin/env bash而不是硬编码/usr/bin/bash或/bin/bash，因为不同系统的bash路径可能不同； - 避免用关联数组这类高版本特性，除非你确认目标环境一定满足。
我从维护过的脚本里总结的教训是：先确认Bash版本，再决定用多少新特性。不要在别人机器上运行到一半才报语法错误，那比运行结果错误还要让人恼火。
7.3 几个小习惯，串起整套防御体系
最后分享几个我每天都在用的小习惯。
第一，写脚本时在头部设置LC_ALL=C，避免不同系统locale导致sort、grep、awk的字符集行为不一致。第二，凡是脚本里要调用的外部命令，先command -v检查存在性再使用，命令缺失时给出明确的安装提示，而不是等到执行时报command not found。第三，日志和错误输出带上时间戳、当前函数名和行号，追查起来会快很多。第四，对涉及删除、覆盖的高危操作做一次演练：跑一遍空数据、跑一遍只读环境，确保没有任何不可逆的输入能看到脚本全貌。这些都是不费什么力气的小习惯，但它们加起来，就是脚本可靠性的分水岭。
写到这里，我又想起最近一次定位线上问题：旧脚本里没有pipefail，数据压缩环节静默失败，第二天业务方拿着不完整的文件找上门。那一刻我特别庆幸，现在团队的新脚本默认都是set -Eeuo pipefail起步，至少这类"假成功"不会再有机会蒙混过关。防御性编程的价值，不是让你写出永远不会错的脚本——Bash没有这种脚本——而是让错误在第一时间、以最明显的方式暴露出来。你愿意的话，也可以从把set -Eeuo pipefail和die函数放进下一个脚本开始，跑一段时间再回头看收益。
