聊 Debian 的 control structures（控制结构），很多人第一反应是语法：if 后面要加 then，for 循环里变量怎么取值，case 的右括号要不要双写。可我在 Debian 上写脚本写了这么多年，发现真正的门槛从来不是背语法，而是在这套系统里怎么用 if、for、while、case 去解决 apt 包管理、服务编排、配置分发、多版本兼容这些每天都要面对的运维问题。控制结构决定了脚本是“一条道走到黑”还是“见路就转弯”，也决定了出问题时你能不能一眼看出病根。
这篇文章我会从 Debian 系统的真实运维场景出发，把四种最常用的控制结构拆开讲清楚，再带一组组合进阶用法和踩坑实录。适合刚开始接触 shell 脚本的入门者，也适合写了不少脚本却总觉得组织混乱的熟练工。代码不多，但每一段都是我在 Debian 服务器上改过好几轮的成品，你可以直接照着用。
1. 从运维场景看控制结构：为什么不是语法题而是生存题
1.1 控制结构在 Debian 系统里的真实角色
Debian 系列系统在服务器领域之所以受欢迎，其中一个原因是它的包管理和服务模型特别适合自动化，而自动化靠的就是一堆 shell 脚本。脚本要干活，就得对环境和状态做判断：包装了没有，服务起没起，目录有没有权限，源配没配对，证书到没到期。这些判断全部要靠控制结构来承载。
你会发现，每一个 if 本质上都是在回答一个问题：这个状态到底存不存在。for是在说：这一批对象要挨个处理，不许漏。while是在等一个条件稳定下来，等到天荒地老也行，但要有超时保护。case则是面对多种分散的状态时做分流的枢纽。把它们组合起来，一个 Debian 脚本才从“一串命令的堆砌”变成“一个有决策能力的程序”。
还有一个容易被忽略的点：Debian 本身的版本分支很多。stable、testing、unstable，还有树莓派这种衍生场景，再加上 Debian 系和 Ubuntu 系经常混在一套运行环境里，包名、源地址、服务名都会不一样。控制结构在这里不是锦上添花，是让脚本活下来的基本能力。遇到公网上的机器，咱们还要考虑源连接超时的情况，这时候if配合curl或apt-get的返回码就特别重要。写控制结构的时候，脑子里必须有“状态机”的概念，否则不如不写。
1.2 一个多发行版兼容脚本，直接带出 if / case / for
我举个真实的例子来把三种结构一次性串起来。假设要给一台新机器自动安装基础工具，但这台机器可能是 Debian，也可能是 CentOS/RHEL 系。你不能一上来就写apt-get install，因为 RPM 系的机器根本没有这个命令。第一版脚本长这样：
#!/usr/bin/env bash detect_family() { if [ -f /etc/os-release ]; then . /etc/os-release case "$ID" in debian|ubuntu) echo "debian-family" return 0 ;; centos|rhel|rocky|almalinux) echo "redhat-family" return 0 ;; esac fi echo "unknown" return 1 } family=$(detect_family) case "$family" in debian-family) update_cmd="apt-get update" install_cmd="apt-get install -y" ;; redhat-family) update_cmd="dnf update -y" install_cmd="dnf install -y" ;; *) echo "不支持的发行版，脚本退出" >&2 exit 1 ;; esac eval "$update_cmd" for pkg in vim screen htop; do eval "$install_cmd $pkg" done这段脚本里，if先判断 os-release 存不存在，case根据系统 ID 分流到不同包管理器，最后for循环批量安装。三个控制结构各司其职，代码读起来非常顺。
不过说句实话，我不建议在脚本里直接用eval，虽然它省事，但一旦变量里掺了特殊字符，很容易把命令搞炸。更稳的方式是把安装动作封装成函数，让case只决定用哪个安装函数：
#!/usr/bin/env bash install_pkg() { case "$family" in debian-family) apt-get install -y "$@" ;; redhat-family) dnf install -y "$@" ;; *) echo "unknown family" >&2; return 1 ;; esac } . /etc/os-release case "$ID" in debian|ubuntu) family="debian-family" ;; centos|rhel|rocky|almalinux) family="redhat-family" ;; *) family="unknown" ;; esac install_pkg vim screen htop这样把控制结构当“分发器”来用，后面维护只需要改一个 case 分支，而不是到处找 eval 替换。我在实际维护运维脚本时，这种写法后来都成了部门里的模板。
2. if / for / while / case：四个最常用的 Debian 运维控制结构
2.1 if 判断：apt 包状态、服务状态、权限检查
在 Debian 系统里，if最密集的使用场景就是包管理。判断一个包有没有装，命令行随手是dpkg -s。
check_pkg() { if dpkg -s "$1" >/dev/null 2>&1; then return 0 fi return 1 } if check_pkg nginx; then echo "nginx 已安装" else echo "nginx 未安装，开始安装..." apt-get install -y nginx || echo "安装失败，请检查网络或 apt 源" fi这里必须要把输出重定向到 /dev/null，还要同时丢弃 stdout 和 stderr，因为dpkg -s在包没安装的时候会在 stderr 输出一长串说明文字，污染你的脚本日志。判断服务状态也遵循同一个思路。Debian 现在默认跑 systemd，简单做法：
if systemctl is-active --quiet nginx; then echo "nginx 运行中" else systemctl start nginx fisystemctl is-active --quiet只在服务 active 时返回 0，这个写法可以安全地用于 if 条件。顺便说一下，如果你要判断服务是否开机自启，就用systemctl is-enabled --quiet nginx，原理一样。
路径和权限判断也经常出现在控制结构里。比如你想写一个脚本自动往/etc/apt/sources.list.d/里添加 docker 源，就得先检查文件存不存在，再检查自己有没有权限写。一般这样写：
if [ -f /etc/apt/sources.list.d/docker.list ]; then echo "docker 源文件已存在" else echo "deb [arch=amd64] ..." > /etc/apt/sources.list.d/docker.list fi if [ ! -w /var/lib/dpkg ]; then echo "当前用户没有 dpkg 写权限，请用 root 或 sudo 重新运行" >&2 exit 1 fiif [ -f ]、if [ -w ]、if [ -x ]是文件判断的基本盘，配合!取反就够覆盖绝大多数场景。有一点你要记住：Debian 的 /bin/sh 是 dash，[[ ]]这个语法在纯 sh 脚本里不能用。如果你的 shebang 写的是#!/bin/sh，那就老老实实用[ ]，别整那些高扩展性的双中括号；如果 shebang 是#!/usr/bin/env bash，那随便用。这个坑后面专门展开。
2.2 for 循环：批量安装依赖、批量处理配置文件
Debian 的日常里，“批量”两个字太常见了。批量装包、批量改配置、批量拉取远程主机信息，全部要靠for。我写批量安装脚本时，基本会先在循环里套一个if做去重判断：
pkg_list=(nginx mariadb-server redis-server php-fpm) for pkg in "${pkg_list[@]}"; do if dpkg -s "$pkg" >/dev/null 2>&1; then echo "$pkg 已安装，跳过" else echo "正在安装 $pkg" apt-get install -y "$pkg" || echo "$pkg 安装失败，请查看日志" fi done这个脚本在全新系统上会依次安装四个服务，在已经装了部分包的系统上则能自动跳过，不会一遍又一遍地重复安装。注意我这里用的是 bash 数组，"${pkg_list[@]}"的写法能正确处理包含空格的包名和路径，这一点比直接在一个字符串里空格分隔要稳得多。
for加通配符遍历是另一种高频玩法。比如想检查/etc/apt/sources.list.d/下所有源文件里到底有哪些有效源，可以直接这样：
for f in /etc/apt/sources.list.d/*.list; do if [ ! -f "$f" ]; then continue fi echo "== 文件：$f ==" grep -Eh '^(deb|Types:)' "$f" || echo "（没有有效 deb 行）" done这里有个细节很多人踩过坑：如果目录下没有匹配*.list的文件，Bash 会把字面量/etc/apt/sources.list.d/*.list当作一个不存在的文件名传给循环。所以循环开头用if [ ! -f "$f" ]; then continue; fi判断一下再继续，是风险最低的写法。continue是控制结构里的“跳过键”，遇到不满足条件的就跳到下一次循环，别让脚本傻乎乎地处理不存在的文件。
2.3 while 循环：逐行读文件、等服务和健康检查
在处理配置文件时，我特别喜欢while read一行一行读，而不是for去遍历命令输出，因为while read能完整处理每一行里的空格和特殊字符。Debian 下读apt源文件筛选有效行的典型写法：
while IFS= read -r line; do case "$line" in ''|'#'*) continue ;; *) echo "有效源: $line" ;; esac done < /etc/apt/sources.listIFS=是为了保证行首行尾的空格不被吃掉，read -r是为了避免反斜杠被当成转义符。重定向放在done后面是最自然的写法，这个位置的done < file对很多人来说不是直觉顺序，但记住一次就不会忘。
while的兄弟until在 Debian 脚本里专门负责“等待类”逻辑。比如装完 sshd 后要等它起来：
attempt=0 until systemctl is-active --quiet sshd || [ "$attempt" -ge 10 ]; do attempt=$((attempt + 1)) sleep 1 done if systemctl is-active --quiet sshd; then echo "sshd 已就绪" else echo "sshd 启动超时，请检查日志" >&2 fiuntil的说法是“直到条件成立才停下”，写出这句语义比while [ ! 条件 ]更容易让人看懂。加[ "$attempt" -ge 10 ]是为了防止死循环，这在 Cron 自动化任务里尤其重要，不然脚本卡死会把整台机器的定时任务串都堵住。健康检查类脚本也常用这个模式，后端服务没有起不来的道理，但确实需要给它时间。
2.4 case 分支：处理 Debian 版本差异和指令分发
case在控制结构里是“多岔路”的存在，最适合处理 Debian 不同版本之间的细微差异。Debian 12 的代号是 bookworm，Debian 13 是 trixie，两个版本之间有些包名会换，软件源地址也会变。写安装脚本时，我一般先读/etc/os-release，再用case分流：
. /etc/os-release case "$VERSION_CODENAME" in bookworm) echo "Debian 12 系列" APT_SOURCE_MAIN="http://deb.debian.org/debian" ;; trixie) echo "Debian 13 系列" APT_SOURCE_MAIN="http://deb.debian.org/debian" ;; *) echo "未知版本：$VERSION_CODENAME" >&2 exit 1 ;; esaccase的另一个经典用途是作为“指令分发器”。你写一个服务管理脚本，第一个参数是 start/stop/restart，后面的动作完全不同，这种场景用 if 会写得很啰嗦，case 一行一个分支非常清晰：
case "$1" in start) systemctl start nginx ;; stop) systemctl stop nginx ;; restart) systemctl restart nginx ;; *) echo "用法: $0 {start|stop|restart}" >&2 exit 1 ;; esaccase支持通配符和正则匹配，比如start|restart)把两个指令合并处理，或者[Rr]estart匹配大小写，这些模式让它在维护路由逻辑时比一串 if 可读性好很多。在 Debian 的安装脚本里，我习惯把所有“版本敏感”的变量都集中在开头一个 case 里定义，后面正文只做引用，这样升级到新版本时只需要改一处。
3. 从能跑到能维护：控制结构组合成 Debian 脚本的进阶套路
3.1 函数 + 控制结构：把脚本改造成模块
脚本写得多了，你会发现纯线性的命令流不靠谱，真正好维护的脚本是“函数 + 控制结构”的组合。比如一个安装前准备函数，它内部需要判断 root 权限、判断网络、判断锁文件是否存在。把每个判断拆成小函数，主流程就只剩调用：
#!/usr/bin/env bash set -u require_root() { if [ "$(id -u)" -ne 0 ]; then echo "请用 root 或 sudo 运行本脚本" >&2 exit 1 fi } check_apt_lock() { if [ -e /var/lib/dpkg/lock-frontend ]; then echo "检测到 dpkg 锁文件，是否有其他 apt 进程在运行？" >&2 return 1 fi return 0 } require_root if check_apt_lock; then echo "锁检查通过，开始安装..." fi函数的好处是：每个函数只干一件事，主流程读起来像是“计划书”。你可以把require_root用在所有要在 Debian 上修改系统的脚本里，一行调用就补上了权限检查，不用每处复制一遍 if。写函数时要注意函数内部的 return 控制结构，它在函数里退出函数，和脚本整体退出不是一回事。我之前见过有人把exit 1直接写在函数里，结果整个脚本直接终止了，那可不是期望的“检查失败后继续走另一个分支”。
3.2 getopts + 循环：让脚本变成带参数的小工具
一个安装脚本如果只处理固定包名，那和硬编码没啥区别。我建议用getopts加case加for把脚本升级成真正的小工具。下面是一个支持-p指定包、-n演练、-v显示版本号的安装脚本骨架：
#!/usr/bin/env bash set -uo pipefail dry_run=0 pkgs=() usage() { echo "用法: $0 [-p 包名] [-n] [-v]" >&2 exit 1 } while getopts "p:nvh" opt; do case "$opt" in p) pkgs+=("$OPTARG") ;; n) dry_run=1 ;; v) echo "$(basename "$0") 1.0"; exit 0 ;; h) usage ;; *) usage ;; esac done if [ "${#pkgs[@]}" -eq 0 ]; then usage fi for pkg in "${pkgs[@]}"; do if [ "$dry_run" -eq 1 ]; then echo "[dry-run] 将会安装: $pkg" else apt-get install -y "$pkg" || echo "$pkg 安装失败" fi done这里有几个关键点。getopts "p:nvh"字符串里，p:后面的冒号表示-p必须带一个参数，参数存在$OPTARG里。while getopts天然就是控制结构和参数解析的组合拳，它会一个个啃掉选项，直到没有可处理的参数为止。set -u在这里很关键，它可以让你在后续代码里放心地使用"${#pkgs[@]}"，万一忘了传-p，脚本会立刻报错而不是悄悄用空值硬跑。
演练模式是我强烈建议加的。在 Debian 上直接apt-get install会动系统全局状态，没经过演练就满世界执行，出问题容易慌了神。加-n参数一旦验证逻辑正确，后续直接在批处理里跑版本就充满底气。
3.3 trap：脚本出事后的最后防线
跑在 Debian 上的脚本，除了正常流程，还得处理中断信号和临时文件残留。trap就是干这个的。我写部署脚本时有一个固定习惯：任何用mktemp生成的临时文件，都注册一个 EXIT 陷阱，退出时自动清理：
tmpfile=$(mktemp) trap 'rm -f "$tmpfile"' EXIT echo "检查配置写入临时文件" cat /etc/nginx/nginx.conf | grep -E "server_name|listen" | head -5 > "$tmpfile" cat "$tmpfile"这样无论脚本正常走完还是中途被 kill，临时文件都不会留在/tmp下面发臭。如果脚本被 Ctrl-C 打断，我还会额外给 INT TERM 信号注册处理：
cleanup() { echo "脚本被中断，清理临时文件" rm -f "$tmpfile" exit 1 } trap cleanup INT TERMtrap cleanup EXIT和trap cleanup INT TERM的区别在于，EXIT 是脚本任何退出路径都会触发，INT/TERM 是收到信号时触发。两个配合起来，才能覆盖“正常结束”和“非正常打断”两种情况。Debian 的 Cron 环境里尤其要注意，trap做清理比到最后手动rm靠谱得多，因为你的脚本不知道什么时候会断在哪儿。
3.4 数组与关联数组：批量管理的现代脚手架
Debian 的 sh 只提供列表，但如果你愿意用 bash，数组和关联数组会大幅提升控制结构的表达力。比如要做一批服务的启停管理，名称和说明放在一个关联数组里：
#!/usr/bin/env bash declare -A services=( [nginx]=web [mariadb]="database" [redis-server]=cache ) for svc in "${!services[@]}"; do role="${services[$svc]}" if systemctl is-active --quiet "$svc"; then echo "$svc（$role）运行中" else echo "$svc（$role）未运行" fi done"${!services[@]}"这种写法是把关联数组的所有键展开，允许你循环处理每一个服务名，再通过服务名去索引它的说明用途。这种写在维护几十个服务的 Debian 服务器时特别有用，备查信息不用到处写 if。不过要记住：这段脚本她不能再叫#!/bin/sh，必须写成#!/usr/bin/env bash，因为关联数组是 bash 扩展语法。Debian 的/bin/sh是 dash，直接跑会报语法错误，这是我经常看到的一个误区。
4. set -e、管道、引号与 locale：Debian 脚本最常见的几个坑
4.1 set -e 的“静默退出”陷阱
写 Debian 脚本，很多人喜欢在开头加set -e，意思是“有命令失败就立刻退出”。但set -e有一个反直觉的地方：在 if 条件、while/until 条件、case 分支、管道左侧，它不会触发退出，因为失败本来就是控制流的一部分。真正让人头疼的是函数内部：
set -e myfunc() { false echo "这一步不会执行" } myfunc echo "整个脚本也不会继续"哪怕false是写在函数里，由于函数整体是在普通命令位置被调用的，false失败后set -e会把整个脚本引爆。这个坑在写 Debian 初始化脚本时特别致命，因为你可能只是想“先检查下某项配置”，结果某一行命令失败，脚本直接中断。我自己的经验是：除非你清楚每个命令的退出状态，否则不要全局开set -e。更稳妥的做法是局部处理失败的命令，比如command || true，或者在确实希望失败就退出的大段流程里才打开set -e。
如果你确实要用set -e，配合set -o pipefail和set -u可以更早暴露问题，但这三个一块用会让脚本变得极其严格，新手很容易被一堆莫名退出搞晕。我给的有效策略是：脚本前 80 行用来解析参数和做检查，这段不开set -e；到了真正执行修改系统的核心段，再打开set -e，这样既能防止半成品状态，又不会因为小检查误伤流程。
4.2 while 管道的变量丢失
这是 Debian 脚本里提问率最高的问题之一。假如你想统计apt源文件有多少行：
count=0 cat /etc/apt/sources.list | while read -r line; do count=$((count + 1)) done echo "$count" # 输出 0你发现count变量根本传不出来。原因是管道右边的while是在一个子 shell 里跑的，循环里修改变量不会影响当前 shell 的count。解决办法有三种：改成进程替换、改成文件重定向、或者把结果写进临时文件再读回来。最直观的是进程替换：
count=0 while read -r line; do count=$((count + 1)) done < <(cat /etc/apt/sources.list) echo "$count"或者更直接，用文件重定向：
count=0 while read -r line; do count=$((count + 1)) done < /etc/apt/sources.list echo "$count"这个坑在 Debian 上用apt list --installed、dpkg -l这类命令的输出做统计时特别常见。我现在的习惯是：只要循环里需要保留状态变量，就一律用重定向或进程替换，不要写管道。管道只适合那些“输出不回流”的场景。
4.3 引号、空格与 glob：控制结构条件里的细节
Debian 文件系统里的路径绝大多数没有空格，但总有一些用户目录或挂载点名字不按常理出牌。判断路径时忘记加引号，是控制结构条件里最不该翻车的翻车点：
dir="/data/my backups" if [ -d $dir ]; then # 会被拆成两个参数 echo "目录存在" fi这个 if 在 Bash 里会报“参数太多”或者判断到错误路径。正确写法是必须加双引号：
if [ -d "$dir" ]; then echo "目录存在" fi另一个和空格相关的坑是通配符没有匹配时，glob 会保留字面量。前面我提到过，在 for 循环里加if [ -f "$f" ]; then continue的原因就在这里。如果你确认目录下会有匹配文件，可以不用管；但如果脚本要跑在一个文件可能为空的部署环境，一定要加上这个防护。也可以使用shopt -s nullglob，让没有匹配时 glob 自动展开为空数组，这样for循环一次都不会执行，也是主流做法。
4.4 locale 与编码：字符串比较和中文匹配的坑
Debian 最小化安装后，很多实例的 locale 是C或C.UTF-8，这个会影响 shell 脚本里对字符串的比较和 grep 匹配。我在某次 Debian 上处理中文配置文件时遇到一个典型问题：用grep "中文关键词"匹配不到任何内容，但文件里明明有这个关键字。查了半天发现是 locale 的问题，LANG=C时某些多字节字符会被当作非法的字节序列处理。这时把环境变量调整一下就好了：
export LC_ALL=C.UTF-8 export LANG=C.UTF-8如果你的脚本要处理日志、配置文件里中文场景，建议在脚本开头统一导出这两个环境变量，避免在if里对字符串做比较或grep时发生不符合直觉的结果。尤其是用case "$line" in *"关键词"*)这种模式去做中文匹配时，保证 locale 正确比什么都重要。
另外，Debian 包列表里的语言包依赖也会受到 locale 影响。如果脚本里需要临时给系统的某个服务设置语言环境，export的位置必须在执行控制结构之前，因为控制结构内部启动的子进程会继承当前 shell 的环境变量，一旦环境不对，里面的判断全都会跟着偏差。
4.5 常见问题速查表
我把 Debian 运维脚本中遇到的高频问题整理成了一个速查表，供排查时快速对号入座。
| 现象 | 可能原因 | 建议处理 |
|---|---|---|
| 安装卡住或报 lock | 另一个 apt/dpkg 进程占用锁 | 先 `ps aux |
| 脚本报 command not found | 非交互 shell 的 PATH 少了/usr/sbin | shebang 用/usr/bin/env bash，脚本内显式export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin |
| 数组语法报错 | 用 sh 执行了 bash 脚本 | 检查 shebang 和调用方式：用bash script.sh，不要sh script.sh |
| systemctl 命令不存在 | 容器或旧系统没有 systemd | 用service封装，或者写if systemctl ...前先command -v systemctl判断 |
| 命令在 if 里正常，脚本外跑失败 | 当前 shell 的退出码被管道或子 shell 吞掉 | 用set -o pipefail，或把要检测的命令放在独立变量里检查 |
这个表不是万能的，但它覆盖了我在 Debian 服务器上写脚本时几乎八成的现场翻车。重点不是背结论，而是排查的时候多问一句：当前这个命令在哪一层 shell 里执行，它的退出码到底是谁的退出码，有没有被管道、子 shell、函数边界给隔离掉。搞清楚这三件套，脚本的稳定性立刻上一个台阶。
最后再分享一个自己坚持了很久的习惯：每写一段if，我都会故意模拟“条件不成立”的路径跑一遍，看脚本是不是按预期躲开危险动作；每写一个for循环，我都会跑一张空列表，看它会不会把字面量当成文件；每写一个case分支，我会把兜底的*)放上去，确保任何未知状态都有退路。控制结构这东西，写的时候多花一分钟，生产环境里就能少熬一夜。
