1. 测试题到底在考什么Linux Shell面试的底层逻辑我面试过不少人也帮团队出过不少 Linux 和 Shell 的测试题说句实话大部分候选人挂在第一轮不是因为不会敲命令而是根本不知道出题人想问什么。Linux Shell 测试题表面上看是考命令、考语法实际上都在考三件事你有没有真正理解 Linux 的工作方式、你在日常工作中是否真的动手写过脚本、以及你遇到问题时的排查思路是否清晰。这三点比背几十个命令重要得多。举个最常见的例子面试题里经常出现“统计某目录下文件数量”这道题很多人顺手就写了ls | wc -l。但如果面试官追问一句“子目录里的文件算不算”“文件名带空格怎么办”“隐藏文件算不算”基本上就能把只背过命令的候选人和真正写过脚本的人区分开。这就是测试题的底层逻辑它不考你知道什么它考你在真实环境下会不会翻车。另一个被高频考察的点是文本处理。什么grep、sed、awk看起来是三个命令实际上代表了三层能力匹配筛选、流式编辑、结构化分析。面试题往往会设计成“给你一个日志文件找出某个时间段的错误并统计数量”这种题没有任何难度但需要你对三者的边界特别清楚——什么时候用grep够了什么时候必须上awk什么时候sed才是最省事的。这些都不是靠背能解决的。再往下就是脚本实战类的测试题。这类题目通常会给你一个场景比如“写一个脚本批量重命名文件”“写一个监控脚本内存使用率超过 80% 就告警”然后让你在纸上或者白板上当场写。这种题的考点其实不在语法而在工程习惯。你会不会做参数校验会不会处理脚本中途失败的情况会不会考虑脚本被重复执行时的幂等性这些细节才是面试官真正想看的。所以如果你正准备 Linux Shell 相关的测试或面试别急着刷题背答案先建立自己的知识地图搞清楚 Shell 测试题到底在哪几个维度上考察然后针对性地补短板。1.1 不同岗位的考核侧重点同样是 Linux Shell 测试题不同岗位的侧重点差别很大这一点很多人没意识到导致复习方向完全跑偏。如果是运维或 SRE 岗位重点一定在日志分析、进程管理、分布式系统的常见操作上。比如top、ps、netstat、ss这些命令的变体考察以及如何通过 Shell 快速定位 CPU 飙高的进程、如何清理过期日志、如何批量同步配置。这类岗位测试题非常实务经常直接拿真实场景来问。如果是后端开发岗位Shell 测试题通常不会考太复杂的文本处理反而更关注 Shell 和系统交互的能力。比如环境变量的加载顺序、如何通过 Shell 调用其他语言写的脚本、如何处理命令行参数。还有一种特别常见的题是“给你一段别人写的 Shell让你指出其中的问题”这种题考的就是代码审查能力。如果是测试开发岗位Shell 测试题几乎必然会涉及自动化相关的内容。比如如何写脚本批量造测试数据、如何用 Shell 做接口回归测试、如何在持续集成流水线里写部署脚本。curl、jq处理 JSON、sed和awk处理返回结果这些频率非常高。这类岗位还喜欢考异常处理因为测试脚本跑在无人值守的环境里失败时必须能自动恢复或者准确告警。如果你还在校或者刚转行不确定自己会面什么岗位那就按“基础语法 文本处理 常见运维场景”三条线同步复习。八成以上的 Shell 测试题都跑不出这个范围把这三条线吃透了基本能应付绝大多数场景。1.2 答题时的通用思路我见过很多候选人题目明明会做但是一紧张就答得乱七八糟想到什么写什么最后连自己都不知道写了啥。这里我分享一个我个人用下来很顺手的答题思路一共四步。第一步先明确输入和输出。题目问的是“找出日志中 5 分钟内访问量最高的 IP”那你就要先想清楚输入是哪个文件、输出格式是什么。不要上来就写命令先在心里把数据流画出来。第二步把大问题拆成小步骤。还是上面那个例子可以拆成先按时间过滤日志再提取 IP 字段再排序去重统计最后取前几个。每一步都是一个独立的命令或管道段。这样拆开之后即使某一步卡住了你也能把其他步骤写出来面试官会知道你的思路是对的不是完全不会。第三步写的时候心里默念“管道和变量”。Shell 测试题绝大多数都能用管道串起来而变量则负责中间状态。如果你发现自己写了一大段却没有用管道也没有用变量那大概率写复杂了回头重新想想。第四步写完后整体检查一遍。检查什么第一命令的参数有没有写错第二管道符和重定向符有没有混第三脚本里有没有用到绝对路径第四有没有考虑文件不存在的情况。这一步非常关键因为测试题往往不是考你不会而是考你粗不粗心。这四步说起来简单但真到了笔试或者白板写代码的时候能坚持下来的很少。我建议你在平时练习时就强制自己按这个流程走形成肌肉记忆考场上才不会乱。2. 经典考点逐个拆解Shell语法层的高频题目Shell 语法层面的题目在测试题里是大头也是最好拿分、最容易丢分的地方。说它好拿分是因为考点非常固定来来去去就那么几个说它容易丢分是因为这些考点都藏在细节里一不留神就写错。先列一个高频考点清单变量的定义与引用、单双引号的区别、特殊变量$?$0$#$$*的含义与区别、命令替换$()和反引号、数学运算$(( ))、逻辑判断中的和||、条件测试[ ]和[[ ]]的区别。基本上一套完整的 Shell 测试题里至少会覆盖一半以上的上面这些点。下面挑几个最容易出错的细讲。2.1 变量、引号与特殊符号三个高频坑变量和引号是 Shell 语法的重灾区几乎每套测试题都会出。先说引号的问题。单引号和双引号最大的区别是单引号里面所有字符都是字面量不具备任何特殊含义双引号里面$、反引号、\依然生效。举个例子nameworld echo hello $name # 输出 hello $name echo hello $name # 输出 hello world这个知识点大家都懂但一到实际题目里就容易出错。我有一次出题故意写了一个echo The file is $HOME/file.txt让候选人判断输出结果结果一半以上的人都认为会输出/home/user/file.txt。这就是被单引号坑了。再说变量引用的边界问题。$name_file和${name}_file在 Shell 里的含义完全不同。前者会被解析成变量name_file后者才是变量name后面拼接_file。这个考点在批量重命名文件的题里特别常见filereport touch ${file}_2024.log如果写成touch $file_2024.log实际上创建的是变量file_2024的值加.log最后文件名完全不对。这种错非常隐蔽自己写的时候很难发现必须对${}的用法形成条件反射。还有一个大坑是命令替换。$(command)和command基本等价但嵌套处理上差距很大。反引号里如果要嵌套命令替换需要转义写起来非常痛苦而$()支持直接嵌套清爽很多。# 推荐写法 dir_count$(ls -l | wc -l) # 反引号的嵌套想想就头疼 dir_count\ls -l | wc -l\现在的新手写脚本我建议直接用$()别碰反引号了除非你在维护老脚本。老脚本里的反引号要特别注意很容易在多层嵌套时出问题。2.2 特殊变量 $?、$0、$#、$ 、$* 的考察方式特殊变量是 Shell 测试题的常客因为它们的应用场景非常具体能直接反映一个人有没有写过真实脚本。$?表示上一条命令的退出状态码0 表示成功非 0 表示失败。这个变量的经典用法是判断命令是否执行成功grep error /var/log/app.log if [ $? -eq 0 ]; then echo 发现错误日志 else echo 日志正常 fi但这里有一个隐藏极深的坑if [ $? -eq 0 ]这一行本身也是一个命令如果你在它之前插入了其他命令$?的返回值就已经变了。更稳妥的写法是先把$?存到变量里。grep error /var/log/app.log ret$? if [ $ret -eq 0 ]; then echo 发现错误日志 fi$0是脚本自身的路径$#是参数个数$和$*是所有参数。这两个从表面看一样实际上差别非常大$把每个参数当成独立的单词$*把所有参数当成一个整体字符串。如果你要遍历所有参数一定要用$而不是$*尤其是参数里可能包含空格的时候。很多测试题会故意在这里设坑比如给你一个文件名my file.txt作为参数让你遍历并操作用$*的写法必然会崩。for arg in $; do echo 参数: $arg done还有一个不常见但偶尔会考的变量是$$它表示当前 Shell 的进程号常见的用途是生成临时文件名避免多进程同时执行脚本时互相覆盖。tmp_file/tmp/tmp_$$.log这种写法在真实脚本里很常见测试题里偶尔会穿插考察。能说出$$的用途通常会被面试官认为是有实际项目经验的。2.3 条件判断中的 [ ] 和 [[ ]] 差异条件判断是 Shell 里最绕的地方测试题几乎必考。[ ]是老牌写法[[ ]]是 bash 的扩展写法两者在功能上有很大差异。最大的差异在变量处理上。[ ]里如果变量未定义很容易报错或者产生意外结果所以需要习惯性加双引号name if [ $name admin ]; then echo 是管理员 fi而[[ ]]对孩子友好得多不加引号也能正确处理空变量name if [[ $name admin ]]; then echo 是管理员 fi另一个差异是正则匹配。[[ ]]支持~正则匹配运算符这是[ ]完全没有的能力。测试题里如果出现“判断字符串是否匹配 IP 地址格式”或者“是否全部由数字组成”那必须用[[ ]]ip192.168.1.1 if [[ $ip ~ ^[0-9]\.[0-9]\.[0-9]\.[0-9]$ ]]; then echo 合法 IP fi[ ]和[[ ]]还支持的条件运算符也有差异。[ ]里用-a表示与-o表示或而[[ ]]里直接用和||。后者更直观也更接近其他编程语言的写法if [ $a -gt 3 -a $b -lt 5 ]; then echo 可以 fi if [[ $a -gt 3 $b -lt 5 ]]; then echo 可以 fi我的建议是只要你确认脚本是用 bash 跑的就一律用[[ ]]少碰[ ]。不仅写法更清晰还能少踩空变量和引号的坑。3. 文本处理三剑客grep、sed、awk的实战拆解文本处理在 Linux Shell 测试题里占比极高因为这是 Shell 最实用、最能解决日常问题的能力。很多人被三剑客的名头吓住其实它们的分工非常明确grep 负责筛选行sed 负责按规则修改文本流awk 负责按列做结构化分析和统计。这三个工具单独拎出来都能写一本书但测试题的范围其实很有限。下面我把历年面试题里出现频率最高的几种考法梳理一遍你按这个方向复习性价比最高。3.1 grep 不只是“找东西”考点全在参数里grep 的基本用法是匹配包含关键字的行但测试题很少直接这么考它会把考点藏在参数里。最常见的考点是-E和-P的区别。-E是扩展正则-P是 Perl 兼容正则。大多数情况下两者够用但涉及复杂正则时建议用-P因为 Perl 正则支持更全面的元字符和断言。还有个非常高频的考法是“排除”也就是-v参数。比如“找出日志里非注释行”grep -v ^# /etc/ssh/sshd_config命令行里写正则记得用引号把正则包起来以免 Shell 把其中的特殊字符解释掉。再说一个很多人栽过的坑grep的退出状态码。当 grep 找不到匹配行时它的退出码是 1而不是 0。这在脚本里会引发连锁反应尤其配合set -e使用时脚本可能意外退出。正确做法是加上|| true或者用条件判断挡住grep error /var/log/app.log || true另外grep -q是非常实用的静默模式不输出内容直接返回退出码适合用于条件判断。如果测试题里问“如何判断文件里是否包含某个关键字但不输出匹配内容”答案就是grep -q。3.2 sed 的增删改查出题人最喜欢考这三个场景sed 是流式编辑器它的典型用法是“一条命令处理一个文件”并且常用-i直接修改原文件。测试题里对 sed 的考察通常集中在删除、替换、范围处理这三个场景。删除行最常见的考法是“删除空行”和“删除指定行”。sed -i /^$/d file.txt sed -i 3d file.txt替换行的考法也很多。比如把文件中所有的foo替换成bar注意全局替换要加gsed -i s/foo/bar/g file.txt如果只替换第一次出现就不加g。这个细微差别经常被忽略但测试题就爱考这种容易被忽略的地方。范围处理是 sed 独有的能力比如处理第 10 到第 20 行之间的内容sed -n 10,20p file.txt这里的-n参数要特别强调默认情况下 sed 会把每一行都输出一遍-n的作用是关闭默认输出只输出被命令处理的行。如果忘记加-n文件里每一行都会被打印一次匹配的行还会被额外打印输出结果会非常混乱。还有一个实用技巧在第 5 行后插入一行内容。sed -i 5a\This is a new line file.txt插入、追加、修改指定行的写法是测试题里的高级考点偶尔也会出现。3.3 awk 的分隔符、内置变量与统计能力awk 在三剑客里最接近编程语言也是测试题里最能拉开分差的工具。它的核心逻辑是“按列处理文本”默认按空格或制表符分隔每一行。先看最经典的写法取出每一行的第几列awk {print $1, $3} file.txt$1 代表第一列$0 代表整行。这个考点太基础一般不会单独出题但会作为后续题目的前置步骤。更常见的考点是自定义分隔符用-F参数指定。比如处理/etc/passwd冒号分隔的格式awk -F: {print $1, $6} /etc/passwd这条命令会输出所有用户名和对应的家目录。类似的场景还有处理 CSV 文件。awk 内置变量 NR 和 NF 也是高频考点。NR 表示当前处理的行号NF 表示当前行的字段数量。比如加行号awk {print NR, $0} file.txt再比如统计每行字段数量用NF即可。统计是 awk 的强项。经典的“统计日志中每个 IP 出现次数”awk {count[$1]} END {for (ip in count) print ip, count[ip]} access.log这段代码把第一列作为数组下标累加最后在 END 块里遍历输出。这个写法在面试里出现频率非常高建议直接背下来并理解每一步的含义。awk 还经常和条件判断组合使用比如“打印第三列大于 100 的行”awk $3 100 {print $0} file.txt这个写法展示了 awk 的模式匹配机制也是测试题的一个固定出题方向。4. 脚本实战从语法到场景题的完整通路前面的内容偏基础和单点知识但真正的测试题尤其是设计题和编程题考察的是把这些知识组合起来解决实际问题的能力。这一章会用几个典型的场景题带着你走完从“题目”到“可运行的脚本”的完整通路。4.1 for 循环与批量处理以及循环里藏着的坑for 循环是 Shell 脚本测试题的常客最常见的场景是批量处理文件、批量执行命令。先看最基础的遍历方式for i in $(ls *.log); do echo 处理文件: $i done这个写法简单但有一个大坑如果文件名里有空格$(ls *.log)的返回值会被按空格拆开导致一个文件被拆成多个“文件”来处理。更安全的写法是直接让 Shell 帮我们做通配符展开for i in *.log; do echo 处理文件: $i done*.log是 Shell 自己展开的展开后每个文件名都是独立的一个“词”即使包含空格也不会出错。这个区别非常基础却是真实生产环境里导致脚本出 bug 的头号原因。for 循环的另一个经典变异是 C 风格循环用于“执行固定次数”的场景for ((i 1; i 10; i)); do echo 第 $i 次 done测试题里如果要你生成 001 到 100 的序列通常需要配合seq和printffor i in $(seq -w 1 100); do echo 文件_$i done这里的-w参数会补齐前导零seq -w 1 100会生成 001 到 100printf也能实现同样的效果。这类数字序列生成的题在批量创建文件或批量重命名的题目里特别常见。4.2 函数与参数传递让脚本具备可维护性测试题里如果让你“写一个脚本完成某某功能”你直接从头写到尾也能得分但如果能把功能拆成函数面试官对你的印象会明显不一样。这就是函数在测试题里的作用区分“能跑”和“写得好”。Shell 函数定义很简单function check_memory() { local threshold$1 local usage usage$(free | awk /Mem:/ {printf %.0f, $3/$2 * 100}) if [ $usage -gt $threshold ]; then echo 警告: 内存使用率 ${usage}% return 1 fi echo 内存正常: ${usage}% return 0 } check_memory 80这里有一个重要细节函数里的local关键字。如果不加local函数里定义的变量就是全局的会影响脚本其他部分。测试题如果考“变量作用域”考的就是这里。参数传递也值得单独说。函数通过$1、$2接收参数而不是括号里的形参。这个和大多数编程语言都不一样也是新手最容易懵的地方。函数的返回值也容易出问题。Shell 函数的return只能返回 0~255 的整数不能返回字符串。要返回字符串只能通过 echo 输出再用$( )捕获function get_username() { echo admin } user$(get_username) echo 当前用户: $user这个模式叫“命令替换 函数输出”在真实脚本里非常常见。测试题中如果既要返回值又要返回状态通常的写法是用echo返回数据用return返回状态码调用方分别捕获。4.3 计划任务与日志清理运维场景题的典型考法运维场景题里日志清理可以说是一道必考题。最常见的需求是“删除 30 天前的日志文件”标准答案是配合find使用find /var/log/myapp -name *.log -mtime 30 -exec rm -f {} \;但这道题通常不会这么简单结束面试官往往会追问如果日志文件名自带日期比如app-2024-01-01.log还有更精确的清理方式吗这时候就需要先提取日期再用date命令做比较而不是单纯依赖mtime。另一个常见场景是定时执行 结果记录。出题形式经常是“写一个脚本每天凌晨 2 点检查磁盘使用率超过 80% 写成告警日志”。这道题需要分两个部分回答一是写脚本二是配置计划任务。脚本部分很简单就是之前讲过的 df awk 条件判断组合#!/bin/bash threshold80 usage$(df / | awk NR2 {print $5} | tr -d %) if [ $usage -gt $threshold ]; then echo $(date %Y-%m-%d %H:%M:%S) 磁盘使用率 ${usage}%, 超过阈值 ${threshold}% /var/log/disk_alert.log fi计划任务部分则要考 crontab 的基本写法0 2 * * * /opt/scripts/check_disk.sh /var/log/script_exec.log 21这里有个很关键的细节在 crontab 里执行脚本环境变量和交互式 Shell 完全不一样。你在命令行里能用的PATH在 crontab 里很可能配置得很有限所以脚本里最好使用命令的绝对路径或者在脚本开头重新设置 PATH。这个坑几乎所有写过定时任务的人都踩过。4.4 并发与后台任务进阶场景题的高分答案当脚本需要处理大量任务比如同时压缩多个目录、批量检测多台服务器端口连通性顺序执行的时间会很长这时候就要用后台任务和并发控制。测试题里偶尔会出现“写脚本同时检测 20 台服务器的连通性”这类题考的就是并发思路。最简单的并发写法是加waitfor ip in 192.168.1.{1..20}; do ping -c 1 $ip /dev/null 21 done wait这个写法让所有 ping 在后台并行执行最后 wait 等待全部完成。但有一个问题如果主机很多同时并发可能打爆服务器这时候就需要控制并发数量。控制并发的经典写法是“令牌桶法”用文件描述符做信号量。这里我给出一个通用模板#!/bin/bash max_jobs5 tmp_fifo/tmp/fifo_$$ mkfifo $tmp_fifo exec 9$tmp_fifo rm $tmp_fifo for ((i 0; i max_jobs; i)); do echo 9 done for ip in $(cat ip_list.txt); do read -r -u9 { ping -c 1 $ip /dev/null 21 echo $ip 存活 || echo $ip 不可达 echo 9 } done wait exec 9-这套写法在真实项目里非常实用但初次看会有点绕。核心思想是先向管道里放入 5 个“令牌”每个任务开始前必须取走一个令牌没有令牌就阻塞等待任务执行完后把令牌还回去让下一个任务继续。这样就能严格保证同一时间最多只有 5 个任务在跑。测试题里能写出并发控制通常会被面试官认为是具备实战能力的信号。5. 那些面试官不会直接告诉你但测试题反复踩的坑Shell 脚本是出了名的“细节决定成败”很多时候不是你不会写而是踩了某些坑导致脚本行为不符合预期。这章我把测试题里出现频率最高的几个坑集中整理一下都是我实际工作中真真切切踩过、带新人时看他们反复踩的。5.1 set -e 会让你的脚本“莫名退出”它不是银弹set -e的作用是任何一条命令返回非零状态码时脚本立即退出。很多人会在脚本开头无脑加上set -e然后发现脚本经常在某一行“无缘无故”退出排查半天也不知道为什么。最常见的坑是“命令在条件判断中返回非零”。在if、while、、||这些上下文里命令的非零返回值是正常的控制流不是错误。但如果你在if里调用了一个返回非零的函数set -e会直接把这个“预期内的失败”当成致命错误导致脚本退出。另一个坑是管道中的命令失败。set -e只检查管道中最后一个命令的退出状态。比如set -e grep error /var/log/app.log | wc -l如果grep没找到内容返回 1但wc -l正常返回 0set -e是感知不到任何异常的脚本会继续跑。想感知管道中间的命令失败需要设置set -o pipefail。所以我的经验是set -e不是不能用而是要有条件地用。在小脚本里它确实能帮你提前发现错误但在大型脚本里它会让你失去对这些“预期失败”的控制。更稳妥的方案是不用set -e而是对关键命令手动检查返回值或者有针对性地对某些命令加|| { echo 失败; exit 1; }。测试题如果问“这个脚本哪里有问题”十有八九会和set -e有关。5.2 管道与子 Shell为什么 while 循环里的变量传不出来管道里的命令是在子 Shell 中执行的这个特性导致了一个非常经典的陷阱在while循环里修改变量循环结束后变量依然保持原值。最典型的例子是统计文件行数count0 cat file.txt | while read line; do count$((count 1)) done echo $count # 输出 0原因就是管道右侧的while在子 Shell 里执行它修改的count是子 Shell 里的副本根本传不回父 Shell。解决办法有两种第一种是用进程替换代替管道第二种是用awk或其他工具直接做统计。count0 while read -r line; do count$((count 1)) done file.txt echo $count # 正确输出 awk {count} END {print count} file.txt这个坑在测试题里出现频率极高因为它直接考察了你对 Shell 进程模型的理解。如果面试官让你写“读取文件里所有 ip统计去重后的个数”直接用管道 while 的大概率会得到错误结果。5.3 IFS 的诡异行为循环里的隐性问题IFSInternal Field Separator是 Shell 的字段分隔符默认值是空格、制表符、换行。环境差异、文件格式差异都可能导致 IFS 的行为不符合预期。最常见的坑是在for循环里。默认情况下for i in $(cat ip_list.txt)会根据 IFS 来拆分内容。如果文件里既有逗号又有空格拆分逻辑会变得很混乱。更坑的是 Windows 格式的文本文件每行结尾是\r\n而 Linux 读文件时只认\n导致每行最后一个字符都带一个\r循环里做字符串匹配或拼接时就会莫名其妙地失败。处理方式是循环里显式设置 IFSIFS$\n for ip in $(cat ip_list.txt); do echo [$ip] done但这里还有第二个坑修改全局 IFS 会影响脚本后面的所有字段拆分。正确做法是修改前保存用完后恢复或者用while read加read命令自带的 IFS 控制while IFS read -r ip; do echo [$ip] done ip_list.txtIFS放在read前面表示这次读取时 IFS 为空read不会自动修剪行首行尾的空白字符。这种写法能保证每一行的原始内容被完整保存不管是空格、制表符还是特殊字符都能原样处理。这个细节如果你能主动在测试题里写出来面试官基本都会在心里给你加分。5.4 引号在变量展开时的“薛定谔状态”变量展开加不加双引号在 Shell 里是一道送命题。测试题喜欢出“请说明以下命令的区别”echo $var echo $var echo $var第一行会按 IFS 对$var的值进行字段拆分还会对包含通配符的字符做路径展开。第二行会把整个值当作一个字符串输出不受拆分影响。第三行是字面量直接输出$var。为什么这个考点重要因为真实生产中文件名里带空格的情况太常见了。如果你在脚本里写了cp $file /backup/而$file的值是report 2024.log这行命令会被拆成两个参数cp就报错了。写成cp $file /backup/才能正确处理包含空格的文件名。我的习惯是拿不准是否该加引号的时候一律加引号。除了特殊情况比如你确实想让变量展开后按 IFS 拆分否则永远用双引号包住变量引用。测试题里只要出现变量引用十有八九就是在考察这个点。6. 一份可以直接抄的备考路线与实操建议前面讲了很多知识点和坑如果你是为了应对面试或者参加测试这一章我直接给出一份按优先级排列的备考清单你可以直接照着练。优先级第一梯队文本处理三剑客。grep、sed、awk这三兄弟必须练到闭着眼能写出来的程度。建议找一份真实的日志文件每天花半小时用三剑客完成“找出 404 请求”“按 IP 统计访问次数”“提取响应时间超过 500ms 的记录”这类练习。这一个阶段练好了等于拿到了 Shell 测试题 30% 以上的分数。优先级第二梯队循环、条件判断、函数等语法结构。注意不要只背语法要结合场景去练。比如给自己定一个任务写一个脚本遍历某个目录下所有.txt文件将文件第一行改为文件名。这个任务会用到 for 循环、变量、sed 的-i、basename命令一箭多雕。优先级第三梯队常见运维场景题。磁盘告警、日志清理、批量部署、服务器连通性检测这四类场景题建议每个都能不看资料写出来。写的时候强迫自己考虑参数校验、文件是否存在、执行失败怎么办这些细节能显著提升代码质量。优先级第四梯队Shell 背后的进程模型和细节。$?、子 Shell、IFS、引号这些最好在写脚本的过程中自己去踩一遍踩过自然就记住了。如果时间不够就重点记上面说到的几个高频坑至少笔试时不会一错再错。最后再唠叨一句练习的时候一定要多动手别光看不写。Shell 是门手艺活手指有没有记忆面试官通过你写代码的速度和流畅度一眼就能看出来。每天花一两个小时坚持一两周应付绝大部分 Shell 测试题和个人项目里的脚本需求都完全够用了。