Shell脚本实战：10个高频面试题解析与避坑指南（附完整代码）

Shell脚本实战：10个高频面试题解析与避坑指南（附完整代码）

最近几年，无论是Linux运维、SRE还是DevOps岗位，Shell脚本能力几乎成了面试的“必答题”。我面试过不少候选人，也作为求职者参加过不少技术面，发现一个有趣的现象：很多人对Shell的基本语法能说个大概，但一到实际编码和场景分析，就容易掉进各种“坑”里。面试官真正想考察的，往往不是死记硬背的概念，而是你能否写出健壮、高效、可维护的脚本，以及面对一个模糊需求时，你的问题拆解和边界思考能力。

这篇文章，我想从一个面试官和一线工程师的双重角度，和你聊聊那些高频出现的Shell脚本面试题。我不会仅仅给你一个“标准答案”，而是会深入剖析题目背后的考察点，分享我踩过的坑，并给出经过生产环境检验的、可直接运行的代码。我们的目标是，让你下次面试时，不仅能答对，还能讲出“为什么这么写更好”，展现出超越平均水平的工程素养。

1. 变量与参数处理：从“能用”到“可靠”

变量和参数是脚本的基石，但这里面的门道比想象中多。面试官抛出这类问题，通常是想看你对细节的把握和对异常情况的处理意识。

1.1 变量引用的“双引号陷阱”

一个经典问题是：“如何安全地处理可能包含空格或特殊字符的文件名？”很多人的第一反应是rm $filename。这恰恰是面试官期待的“错误答案”。

核心考察点：你是否了解Shell的“单词分割”（Word Splitting）机制。当变量不加引号展开时，Shell会按空格、制表符、换行符（由IFS定义）将其拆分成多个部分。

# 危险的做法 filename="My Important File.txt" rm $filename # 实际执行的是：rm My Important File.txt，试图删除三个文件！ # 正确的做法：始终使用双引号包裹变量引用 rm "$filename"

但仅仅知道加引号还不够。在复杂的命令替换中，陷阱更多。比如，用find命令获取文件列表：

# 看似正确，实则危险 files=$(find . -name "*.log") for f in $files; do echo "Processing: $f" done

如果文件名包含换行符，这个循环就会出错。更健壮的做法是使用while read循环配合find -print0：

# 健壮的处理方式 find . -name "*.log" -print0 | while IFS= read -r -d '' file; do echo "Processing: $file" done

提示：-print0使用空字符（ASCII NUL）作为分隔符，这是唯一不会出现在合法文件名中的字符，配合read -d ''可以安全处理任何古怪的文件名。

1.2 特殊变量与参数扩展的实战技巧

$?,$#,$@,$*这些特殊变量大家都会背，但面试官喜欢问它们的区别，尤其是$@和$*。

• $@：每个参数都是一个独立的、带引号的单词。是迭代所有位置参数的首选。
• $*：将所有参数连接成一个单词，由IFS的第一个字符分隔。

区别在需要保留参数原始含义时至关重要。看一个例子：

#!/bin/bash # script.sh echo "Using \$@:" for arg in "$@"; do echo "[$arg]" done echo -e "\nUsing \$*:" for arg in "$*"; do echo "[$arg]" done

执行./script.sh "arg one" "arg two"，输出将是：

Using $@: [arg one] [arg two] Using $*: [arg one arg two]

参数扩展是另一个能体现功力的地方。比如，面试题常考“批量修改文件后缀”。初级写法是用字符串替换，但更好的方法是使用参数扩展：

# 将目录下所有 .txt 文件改为 .md for file in *.txt; do # ${file%.txt} 移除 .txt 后缀 # ${file##*.} 可以获取扩展名 mv -- "$file" "${file%.txt}.md" done

这里--参数用于明确指示选项结束，防止文件名以-开头时被误认为是选项，这是编写可靠脚本的一个小细节。

2. 条件测试与流程控制：写出清晰的逻辑

条件判断是脚本的逻辑核心。面试官不仅看你是否记得-eq和==的区别，更看你能否写出清晰、无歧义、兼容性好的判断语句。

2.1[ ]与[[ ]]的选择

这是一个高频考点。传统的[（test命令）和Bash内置的[[关键字，在功能和行为上有显著差异。

面试建议：如果明确环境是Bash（脚本以#!/bin/bash开头），优先使用[[，因为它更安全、功能更强。例如，正则匹配只能用在[[中：

# 判断变量是否为纯数字 if [[ $input =~ ^[0-9]+$ ]]; then echo "Valid number." fi

如果考虑脚本的可移植性（需要在dash等精简Shell中运行），则必须使用[，并时刻注意变量加引号：

# 可移植的写法 if [ "$input" -eq "$input" ] 2>/dev/null; then echo "Likely a number." fi # 技巧：尝试做算术比较，失败则不是数字

2.2 循环与分支的实战模式

for循环遍历文件列表时，直接使用通配符*可能会遇到“无匹配”的问题：

# 如果当前目录没有 .log 文件，file 会被赋值为字面字符串 "*.log" for file in *.log; do echo "Found: $file" done

更安全的模式是启用nullglob选项，或者在循环内检查文件是否存在：

# 方法一：使用 nullglob shopt -s nullglob for file in *.log; do echo "Found: $file" done shopt -u nullglob # 方法二：显式检查 for file in *.log; do # 检查是否是真实存在的文件（而非字面字符串） if [[ -e "$file" ]]; then echo "Found: $file" fi done

case语句在匹配模式时非常高效，比一连串的if-elif更清晰。面试时如果能用case优雅地处理多个选项，会很加分：

read -rp "Enter action (start|stop|restart|status): " action case "$action" in start|s) start_service ;; stop|p) stop_service ;; restart|r) restart_service ;; status|t) check_status ;; *) echo "Usage: $0 {start|stop|restart|status}" exit 1 ;; esac

3. 函数与代码组织：迈向模块化

当脚本逻辑变复杂时，函数是组织代码、避免重复的关键。面试中要求写一个稍复杂的脚本时，主动使用函数是专业性的体现。

3.1 函数的定义、返回值与作用域

Shell函数的返回值不是通过return语句返回数据，而是通过退出状态码（0表示成功，非0表示失败）。要返回数据，通常使用全局变量、子Shell输出或者命名管道（FIFO）。

#!/bin/bash set -euo pipefail # 好的实践：启用严格模式 # 一个计算阶乘的函数，通过“回声”返回值 calculate_factorial() { local n=$1 local result=1 for ((i=1; i<=n; i++)); do result=$((result * i)) done echo "$result" # 将结果打印到标准输出 } # 调用函数并捕获输出 factorial_of_5=$(calculate_factorial 5) echo "5! = $factorial_of_5" # 另一个函数，通过引用传递变量名来修改其值 increment_counter() { local -n counter_ref=$1 # 使用 nameref (Bash 4.3+) counter_ref=$((counter_ref + 1)) } my_counter=10 increment_counter my_counter echo "Counter is now: $my_counter" # 输出 11

注意函数内部的local关键字，它用于声明局部变量，避免污染全局命名空间。这是编写可维护脚本的重要习惯。

3.2 错误处理与脚本健壮性

面试官非常看重脚本的健壮性。一个脚本在参数错误、文件不存在、命令执行失败时应该如何表现？

使用set命令开启严格模式是一个黄金法则：

#!/bin/bash set -euo pipefail # -e: 任何命令失败（返回非零）则立即退出脚本。 # -u: 使用未定义的变量时报错。 # -o pipefail: 管道中任意一个命令失败，整个管道返回失败状态。

但这还不够。对于可能失败的、但又可以接受失败的操作，需要显式处理：

# 尝试删除一个可能不存在的临时文件 rm -f "/tmp/temp_$$.data" 2>/dev/null || true # `|| true` 确保即使 rm 失败（文件不存在），脚本也不会因 set -e 而退出

对于关键操作，应该记录详细的日志，并检查返回值：

backup_file() { local src=$1 local dest="${src}.bak.$(date +%s)" if ! cp -p "$src" "$dest"; then # 记录错误到标准错误和系统日志 echo "ERROR: Failed to backup $src to $dest" >&2 logger -t "$(basename "$0")" "Backup failed for $src" return 1 fi echo "Backup created: $dest" return 0 }

4. 文本处理三剑客：grep, sed, awk

文本处理是Shell脚本的强项，也是面试的重灾区。题目往往不是让你背命令参数，而是考察你能否用最合适的工具高效解决问题。

4.1 根据场景选择工具

很多候选人一上来就用awk，但有时grep或sed更简单高效。我的选择原则是：

• grep：主要用于查找匹配特定模式的行。它的核心优势是速度快，选项丰富（-i忽略大小写，-v反向匹配，-E扩展正则，-A/-B/-C显示上下文）。
• sed：主要用于对行的基本转换，如替换、删除、插入。它按行流式处理，适合简单的、基于行的编辑任务。
• awk：当处理需要基于列、进行计算或逻辑判断的复杂文本时，它是首选。它本身是一门编程语言，功能强大。

看一个面试题：“提取nginx访问日志中状态码为5xx的请求，并统计每个URI出现的次数”。这需要组合使用。

# 假设日志格式为：$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent logfile="access.log" # 1. 用grep过滤出5xx错误 # 2. 用awk提取第7列（假设"$request"中的URI在日志的第7列，具体需根据格式调整） # 3. 用sort和uniq计数 grep ' 5[0-9][0-9] ' "$logfile" | awk '{print $7}' | sort | uniq -c | sort -nr # 更精确的awk单行版本，直接在awk里完成过滤和统计 awk '$9 ~ /^5[0-9][0-9]$/ {count[$7]++} END {for (uri in count) print count[uri], uri}' "$logfile" | sort -nr

4.2 sed与awk的进阶用法

sed的-i选项用于原地修改文件，但这是一个危险操作，面试时一定要提到备份。

# 错误的做法：直接修改，没有备份 sed -i 's/foo/bar/g' important.conf # 正确的做法：先测试，或使用-i.bak创建备份 sed -i.bak 's/foo/bar/g' important.conf # 或者更安全：先输出到新文件，确认无误后再替换 sed 's/foo/bar/g' important.conf > important.conf.new && mv important.conf.new important.conf

awk的数组和内置函数是解题利器。比如面试题：“有一个CSV文件（字段以逗号分隔），请计算第二列数值的总和和平均值”。

#!/bin/bash # data.csv 内容示例： # name,score,grade # Alice,95,A # Bob,87,B # Charlie,92,A awk -F',' ' NR > 1 { # 跳过标题行 sum += $2 count++ } END { if (count > 0) { avg = sum / count printf "Total: %d\nAverage: %.2f\n", sum, avg } else { print "No data found." } }' data.csv

5. 实战编程题深度剖析

现在，我们来看几个融合了多个知识点的综合实战题。这些题目的“坑”往往不在语法，而在对需求的理解和边界条件的处理上。

5.1 监控进程并自动重启

这是经典的运维面试题。一个朴素的实现可能如下：

#!/bin/bash PROCESS_NAME="myapp" if ! pgrep -x "$PROCESS_NAME" > /dev/null; then echo "$(date): Process $PROCESS_NAME is down, restarting..." /usr/local/bin/myapp --daemon fi

但这个脚本问题很多：

1. 竞态条件：在pgrep和启动命令之间，进程可能已经被其他脚本启动。
2. 启动失败：没有检查启动命令是否成功。
3. 日志风暴：如果进程频繁崩溃，这个脚本会不断打印日志并尝试重启，可能产生大量日志或导致启动风暴。
4. 无法处理多个实例：pgrep -x可能匹配到多个同名进程。

一个更健壮的版本应该考虑这些因素：

#!/bin/bash set -euo pipefail PROCESS_NAME="myapp" PROCESS_CMD="/usr/local/bin/myapp --daemon" LOCK_FILE="/tmp/${PROCESS_NAME}_monitor.lock" LOG_FILE="/var/log/${PROCESS_NAME}_monitor.log" MAX_RESTARTS=3 RESTART_WINDOW=60 # 秒 # 使用文件锁，防止脚本并发执行 exec 9>"$LOCK_FILE" if ! flock -n 9; then echo "$(date -Is): Another monitor instance is running. Exiting." >> "$LOG_FILE" exit 0 fi # 记录日志的函数 log_message() { echo "$(date -Is): $*" >> "$LOG_FILE" } # 检查进程是否健康，不仅仅是存在 check_process_health() { # 使用pidof获取精确的PID列表 local pids pids=$(pidof "$PROCESS_NAME" 2>/dev/null) if [[ -z "$pids" ]]; then return 1 # 进程不存在 fi # 这里可以添加更复杂的健康检查，比如检测端口是否监听 # 例如：nc -z localhost 8080 >/dev/null 2>&1 return 0 } # 主逻辑 if ! check_process_health; then log_message "Process $PROCESS_NAME is not healthy. Checking restart rate..." # 简单的重启频率控制：检查过去RESTART_WINDOW秒内重启次数 local recent_restarts recent_restarts=$(grep -c "Attempting to restart" "$LOG_FILE" 2>/dev/null || echo 0) # 这里需要更精确的时间窗口判断，简化示例 if [[ $recent_restarts -ge $MAX_RESTARTS ]]; then log_message "ERROR: Too many restarts in a short period. Giving up. Manual intervention required." exit 2 fi log_message "Attempting to restart $PROCESS_NAME..." if $PROCESS_CMD; then sleep 2 # 给进程一点启动时间 if check_process_health; then log_message "Restart successful." else log_message "WARNING: Process started but health check failed." fi else log_message "ERROR: Failed to execute restart command." exit 1 fi else log_message "Process $PROCESS_NAME is healthy." # 生产环境可能减少健康日志频率 fi # 释放锁 flock -u 9

这个脚本引入了文件锁、健康检查、重启频率限制和更详细的日志，明显更接近生产环境的要求。

5.2 查找并清理过期日志文件

另一个常见需求是清理。题目可能是：“写一个脚本，删除/var/log/app/目录下超过30天的.log文件，但在删除前进行压缩备份。”

#!/bin/bash set -euo pipefail LOG_DIR="/var/log/app" BACKUP_DIR="/backup/logs" RETENTION_DAYS=30 COMPRESS_CMD="gzip" # 也可以是 bzip2, xz 等 # 创建备份目录（如果不存在） mkdir -p "$BACKUP_DIR" # 使用 find 定位文件，-mtime +30 表示修改时间在30天以前 # -type f 只找文件， -name 匹配文件名 find "$LOG_DIR" -type f -name "*.log" -mtime +"$RETENTION_DAYS" | while IFS= read -r logfile; do # 获取相对路径，用于在备份目录中保持目录结构 relative_path="${logfile#$LOG_DIR/}" backup_file_path="$BACKUP_DIR/${relative_path}.$(date +%Y%m%d).gz" # 创建目标目录 mkdir -p "$(dirname "$backup_file_path")" echo "Processing: $logfile" # 压缩并备份 if $COMPRESS_CMD -c "$logfile" > "$backup_file_path"; then echo " -> Backed up to: $backup_file_path" # 验证备份文件完整性 if $COMPRESS_CMD -t "$backup_file_path" &>/dev/null; then # 删除原文件 rm "$logfile" echo " -> Original file removed." else echo " -> ERROR: Backup file integrity check failed! Skipping deletion." >&2 rm -f "$backup_file_path" # 删除损坏的备份 fi else echo " -> ERROR: Compression failed for $logfile" >&2 fi done echo "Cleanup completed."

这个脚本展示了如何安全地串联多个操作：查找、备份、验证、删除。其中$(dirname "$backup_file_path")用于动态创建子目录，${logfile#$LOG_DIR/}使用了参数扩展移除路径前缀，这些都是很实用的技巧。

面试时，如果你能写出这种考虑周全、包含错误处理和回滚逻辑的脚本，并解释清楚每一步的意图和潜在风险，无疑会大大增加面试官的好感。记住，代码是写给人看的，偶尔给机器执行。清晰、健壮、可维护，是Shell脚本高手的共同追求。