引言

Shell脚本几乎贯穿了每位后端开发、运维工程师的日常工作：从简单的文件批量重命名、服务启动关闭，到复杂的CI/CD流水线、系统监控告警。然而，很多脚本都停留在“能跑就行”的原始阶段——没有错误处理、变量随意拼接、逻辑揉成一团，经常在换了个环境或遇到边界条件时就悄悄崩溃，留下一地鸡毛。

编写高质量的Shell脚本并不是一件难事，只要遵循一套经过验证的最佳实践，就能极大地提升脚本的健壮性、可读性和可维护性。本文将从规范、安全、日志、函数设计等多个维度，结合一个完整的实战示例，帮助你建立一套属于自己的Shell编写方法论。

核心概念与最佳实践

在开始写代码前，我们先梳理出几个贯穿脚本始终的核心原则。这些原则就像地基，决定了你的脚本是临时拼凑的木板房，还是能抗风雨的钢筋混凝土建筑。

1. 严格开头的“安全三件套”

几乎所有的健壮脚本都应该以以下三行开头：

#!/bin/bash set -euo pipefail IFS=$'\n\t'

• set -e：任何命令返回非零退出码时立即终止脚本，避免错误被忽略后继续执行，造成更大的混乱。
• set -u：使用未定义的变量时直接报错退出，防止因变量名拼写错误导致诡异 bug。
• set -o pipefail：管道命令中只要有一个命令失败，整个管道的返回码就是失败的，而不仅仅是最后一个命令的返回值。这样你就不会漏掉管道中间步骤的错误。
• IFS=$'\n\t'：将内部字段分隔符设置为换行和制表符，避免因空格切割导致的文件名、参数解析异常。这一点在处理文件名包含空格时尤其重要。

有时候你可能需要临时关闭某些选项，例如在一个可能返回非零状态但业务上允许的命令中，可以使用set +e和set -e包裹。

2. 变量与引用的铁律：处处加双引号

Shell中，变量替换的分词（word splitting）是无数bug的来源。永远用双引号包裹变量，除非你明确知道自己在做分词操作。

# 错误：如果filename是 "my file.txt"，会被拆成两个参数 cp $filename /destination # 正确 cp "$filename" /destination

对于命令替换同样如此：

current_date=$(date "+%Y-%m-%d") echo "Today is $current_date"

养成习惯：凡变量引用，必加双引号（"$var"）。这是最简单、回报最高的防御措施。

3. 可读性至上：命名、注释与缩进

脚本不仅仅是写给机器看的，更是写给未来的你和你的同事看的。
-变量命名：使用小写字母加下划线，环境变量和常量可以使用大写。例如backup_dir、MAX_RETRY_COUNT。
-函数命名：动词开头，见名知意，如check_dependencies、upload_to_s3。
-注释：每个脚本开头用一段注释描述脚本的用途、参数、作者和修改记录。复杂逻辑块前必须写注释。
-缩进：使用4个空格（不要混用tab）。函数体、if/for等结构清晰缩进。

4. 函数化：拆解复杂逻辑

将重复逻辑抽取成函数，即使只调用一次，也能提高代码的自解释性。函数内部变量使用local声明，避免污染外部作用域。

log_info() { local message="$1" echo "[INFO] $(date '+%Y-%m-%d %H:%M:%S') $message" }

5. 错误处理与清理：trap的妙用

脚本退出（无论正常还是异常）时往往需要清理临时文件、释放锁等。使用trap注册清理函数，让你的脚本“人走茶凉”。

cleanup() { # 删除临时目录等 rm -rf "$TEMP_DIR" } trap cleanup EXIT

trap还可以捕获 INT (Ctrl+C) 和 TERM 信号，确保优雅终止。

6. 日志分层与输出

不要到处echo，用专门的日志函数区分信息、警告、错误。错误信息输出到标准错误（stderr）。

log_info() { echo "[INFO] $*"; } log_warn() { echo "[WARN] $*" >&2; } log_error() { echo "[ERROR] $*" >&2; }

这样，你可以轻松地将正常输出重定向到文件，而错误仍显示在终端。

实战示例：构建一个健壮的目录备份脚本

下面我们将以上最佳实践融入一个真实场景——编写一个backup.sh脚本，用于将指定目录压缩打包，并上传到远程服务器（本示例用本地另一个目录模拟远程）。脚本需支持参数配置、依赖检查、错误处理、日志输出和临时文件清理。

完整脚本如下，你可以直接保存并运行测试：

```bash

!/bin/bash