写Shell脚本最烦什么？我猜十有八九是"改一个文件，再改第二个，再改第三个"这类重复劳动。我第一次被Shell循环打动，是当时要给几十个配置文件的同一位置插入一行参数。手动改到第三个文件的时候，我停下来想：这活儿不该这么干。于是第一次认认真真写了一个for循环，三行代码，跑完收工。那一刻我才意识到，循环不是Shell的一个语法点，而是Shell脚本的灵魂。这篇文章就把我这些年写循环的经验整理出来，从语法细节到实战用法，再到我踩过的坑和性能优化思路，一次性说透。写给刚开始接触Shell脚本的同学，也写给已经写了一阵子但总觉得循环里有些行为"怪怪的"朋友。
1. 循环的真正价值：从重复劳动到自动化
1.1 一个真实场景：给50台服务器更新配置
先说一个最典型的场景。假设我手里有一批服务器，IP列表放在server.list文件里，每行一个IP。我需要登录每台机器，修改/etc/ssh/sshd_config里的某个参数，然后重启服务。没有循环的时候，我只能一台一台敲，50台就是50遍，中间还容易漏。
用while循环加read，整个任务变成这样：
while read ip; do ssh user@$ip "sed -i 's/#MaxAuthTries 6/MaxAuthTries 3/' /etc/ssh/sshd_config; systemctl restart sshd" done < server.list这个例子虽然简单，但它把两个核心能力组合在了一起：一是逐行读取文件，二是对每一行执行一组命令。循环在这里做的事情，本质上是一个"迭代器"——把重复的工作抽象成规则，剩下的交给机器。
类似的应用还有批量创建用户、批量推送公钥、批量备份日志、批量清理临时文件。你会发现，只要出现了"对一批东西做同一件事"的需求，循环就是最自然的表达方式。
1.2 循环选型第一课：什么时候用for，什么时候用while
很多初学者一上来就问：for和while有什么区别？我用一句话回答：for循环强在"遍历已知列表"，while循环强在"等待条件变化"或"逐行消费输入"。这不是教条，而是两种循环在设计目标上的本质差异。
for循环适合的场景：遍历一组文件名、遍历一个数组、遍历一段数字序列。比如：
for file in *.log; do echo "处理 $file" done这里*.log先被Shell展开成具体的文件名列表，然后for逐个赋值给变量。这个过程是"先有完整列表，再依次处理"。
while循环适合的场景：从文件逐行读取、监听某个进程的退出状态、轮询等待某个接口可用、写一个永不退出的守护式循环。它的特点是"每次迭代都依赖上一轮的状态变化"，所以天然适合处理流式输入和条件监控。
until循环则是while的镜像：while是条件为真就继续，until是条件为假才继续。实际用得少，但在"等待一个动作完成"的场景里有奇效。
我把三者的选择逻辑总结成一个表格，方便对照：
| 循环类型 | 适用场景 | 退出时机 | 典型例子 |
|---|---|---|---|
| for | 列表已知，遍历处理 | 列表耗尽 | 批量重命名文件 |
| while | 条件驱动，逐行消费 | 条件变为假 | 读文件、轮询状态 |
| until | 等待条件达成 | 条件变为真 | 等待端口开放 |
2. 三种循环的语法细节与执行逻辑
2.1 for循环的四种写法
for循环的写法比很多人想象中多。我见过最混乱的脚本，一屏里混着三四种写法，阅读体验极差。但其实只要掌握下面几种就够了。
第一种，遍历显式列表：
for name in alice bob charlie; do echo "hello, $name" done第二种，遍历通配符展开的结果：
for conf in /etc/nginx/conf.d/*.conf; do echo "检查 $conf" done这里有个细节：如果/etc/nginx/conf.d/下没有任何.conf文件，Shell会把字面字符串/etc/nginx/conf.d/*.conf直接传给for，而不是报错。所以严谨的脚本会在前面先判断是否存在匹配：
shopt -s nullglob for conf in /etc/nginx/conf.d/*.conf; do echo "检查 $conf" donenullglob打开之后，没有匹配时列表就为空，循环体一次都不执行。这个开关很小，但能在自动化脚本里救你一命。
第三种，C语言风格的数字循环：
for ((i=1; i<=10; i++)); do echo "第 $i 次迭代" done这种写法适合明确知道循环次数、并且需要用到递增计数的场景。注意两个括号中间的空格不能随意省略，写成for((i=1...))在部分Shell版本也能跑，但为了可读性我建议保留空格。
第四种，遍历命令替换的结果：
for line in $(cat urls.txt); do echo "url: $line" done这个写法能跑，但我要提醒一句：$(cat urls.txt)会按空格和换行做单词拆分，如果文件里有一行内容包含空格，就会被拆成两段。后面章节我会专门展开讲这个问题。
2.2 while循环与read组合：逐行处理文本的正确姿势
逐行读文件是Shell脚本里最高频的需求之一。标准写法是：
while IFS= read -r line; do echo "读到: $line" done < input.txt这里有几个不起眼但至关重要的细节。
IFS=的意思是清空字段分隔符。read默认会用空格、制表符、换行符作为分隔符，把读到的内容拆成多个字段。如果把IFS清空，read就会把整行原样塞进变量，行首行尾的空格也得以保留。这在处理带缩进的配置文件时非常有用。
-r参数禁止read对反斜杠做转义处理。如果不加，输入里的\n字符串会被当成换行符处理，配置文件里的路径一旦包含反斜杠就全乱了。-r是逐行读取的标配，没有特殊理由不要省。
还有一点经常被忽略：这个while是在子Shell里执行吗？不是的。因为重定向符号< input.txt是加在while关键字后面，而不是管道的右侧。如果写成cat input.txt | while ...，那这个while就是在子Shell里跑的，循环里对变量的修改，循环结束后全部丢失。这个坑我后面专门说。
2.3 until循环与退出码思维
until循环的核心价值在于"等待一个预期的结果"。比如等一个服务端口从关闭变到开启：
until nc -z 127.0.0.1 8080; do echo "端口还没开，继续等..." sleep 2 done echo "服务已就绪"nc -z只探测端口通不通，成功时返回退出码0，失败时返回非0。until的行为就是：只要命令返回非0，就继续循环；直到返回0，才停止。所以你要等待的目标，本质上就是"让某个命令变成成功的状态"。
这个思维的妙处在于，你可以把任何"探测动作"封装进until里。比如等一个文件出现：
until [ -f /tmp/ready.flag ]; do sleep 1 done再比如等一个进程退出：
until ! pgrep -f "batch_job.py" > /dev/null; do echo "任务还在跑，等待中..." sleep 5 done这里!对退出码取反，这样until就变成了"当进程不存在时停止循环"。写多了你就会发现，循环条件并不只能写文件判断、数字比较，任何命令都可以作为条件，只要它返回值对得上。
2.4 break、continue、exit的作用域与循环控制
循环控制有三个关键字经常混用：break、continue、exit。它们的区别可以直接决定脚本行为，尤其要注意嵌套循环时代码"跳出"到哪里。
break：跳出当前这一层循环。continue：跳过本次迭代，进入下一次。exit：退出整个脚本进程，后续所有代码都不执行。
嵌套循环里，break只会跳出一层。如果想跳出两层循环，可以用break 2。数字表示退出多少层：
for ((i=1; i<=3; i++)); do for ((j=1; j<=3; j++)); do if [ $j -eq 2 ]; then break 2 fi echo "$i - $j" done done上面这段代码只会输出1 - 1，然后直接跳出两层循环。continue也有类似用法continue 2，但实际场景里用得比break 2少得多。
exit虽然不属于循环控制关键字，但我在循环里经常用它来"发现问题时直接终止整场任务"。比如批量处理文件时发现磁盘满了，继续跑下去只会制造更多半成品文件，这时候exit 1就是最合理的选择。
3. 实战案例：文件遍历、批量处理与文本解析
3.1 批量重命名文件
批量重命名是我认为最能体现循环价值的入门例子。假设一个目录里有大量photo_2023_*.jpg文件，我要把年份从2023改成2024。直接用mv手动改名显然不现实，写个循环就清晰了：
for file in photo_2023_*.jpg; do newname="${file/2023/2024}" mv "$file" "$newname" echo "重命名: $file -> $newname" done${file/2023/2024}是Shell的字符串替换语法，只替换第一个匹配。循环里每次迭代只处理一个文件，逻辑简单，出错了也容易定位。需要提醒的是，所有变量引用必须加双引号，否则文件名带空格时，mv会收到被拆开的参数，命令直接失败。
如果重命名规则更复杂，比如把扩展名从.txt改成.md，同时把文件名改成小写，可以用参数扩展结合tr：
for file in *.TXT; do basename="${file%.TXT}" newname="$(echo "$basename" | tr 'A-Z' 'a-z').md" mv "$file" "$newname" done循环在这里的价值是：让每个文件的处理逻辑互相独立，新增规则只要在循环体里加一行。
3.2 遍历目录与嵌套循环
遍历目录是另一个频繁需求。只处理当前目录下的文件当然简单，但如果要递归子目录，情况就复杂了。一个朴素的方案是用嵌套for：
for dir in */; do echo "进入目录: $dir" cd "$dir" || continue for file in *.conf; do echo "处理: $dir/$file" done cd .. done这个方案能跑，但cd来cd去容易出错，一旦某个目录cd失败，后面全乱。所以我会换一种思路：用find先把文件列表生成好，再交给for循环：
while IFS= read -r -d '' file; do echo "处理: $file" done < <(find /etc -name "*.conf" -type f -print0)这里用-print0让find输出以空字符分隔的文件名，再配合read -d ''逐行读取。这样做的好处是：文件名不管带空格、换行还是特殊字符，都不会被错误拆分。< <(...)的写法叫进程替换，它让while在当前的Shell进程中执行，循环内的变量修改不会丢失。
这个组合我几乎天天用，它是处理"任意复杂文件名列表"的最稳妥姿势。
3.3 用循环读文件逐行处理
逐行处理文本时，最常见的是处理日志、CSV、配置清单。比如一个简单的日志分析需求：从access.log中提取所有返回码为500的行，并统计次数。
count=0 while IFS= read -r line; do if echo "$line" | grep -q " 500 "; then count=$((count+1)) echo "$line" >> errors.log fi done < access.log echo "500错误总数: $count"这个例子把读取、过滤、累加、写文件串在一起。每行处理逻辑都写在循环体里，方便后续加复杂判断。但要说性能最优，同等场景直接用grep加wc -l更快：
grep " 500 " access.log | wc -l所以这里有个取舍：如果只是找出符合条件的行，用管道命令一行搞定；如果每一行还需要额外的逻辑处理，才用循环。循环的价值不在炫技，而在表达"逐行执行一系列规则"的能力。
3.4 循环里跑grep：统计日志与提取关键信息
把grep放进循环里，是Shell脚本里非常常见的组合。比如我要统计一批日志文件中各包含多少条错误信息：
for logfile in /var/log/app/*.log; do error_count=$(grep -c "ERROR" "$logfile") echo "$logfile: $error_count 条错误" donegrep -c直接输出匹配行数，不需要再套一层wc。这个脚本可以快速对比多份日志的错误密度。
还有另一个高频用法：循环遍历多个关键词，统计每个关键词的出现次数：
keywords=("timeout" "refused" "fail") for kw in "${keywords[@]}"; do cnt=$(grep -c "$kw" /var/log/backend.log) echo "关键词 $kw 出现 $cnt 次" done注意这里数组遍历的写法"${keywords[@]}"一定要把整个数组展开成多个独立的词。如果写成${keywords[*]}，所有元素会被合成一个字符串，循环只会执行一次。这个区别我在写脚本时栽过跟头，后来凡是数组遍历，一律用[@]。
4. 循环中的坑与性能陷阱
4.1 for循环通配符不展开的经典坑
前面提到过nullglob，这里展开说一下。默认情况下，如果一个通配符没有匹配到任何文件，Shell不会报错，而是把通配符本身当作字面字符串。于是你的脚本可能"静默处理"了一个根本不存在的文件，而且完全无感知：
for f in /tmp/nonexistent/*.txt; do rm "$f" done如果匹配不到任何文件，f的值就是字面字符串/tmp/nonexistent/*.txt，rm会收到一个不存在的路径，然后报错。表面上是脚本bug，实际上是通配符展开的语义问题。
对策一是直接判断：
shopt -s nullglob files=(/tmp/nonexistent/*.txt) if ((${#files[@]} > 0)); then for f in "${files[@]}"; do rm "$f" done finullglob让未匹配的列表变成空数组，然后通过数组长度判断是否进入循环。这个模式值得记住：复杂脚本里，先用数组接收列表，再遍历数组，比直接用for接通配符更容易控制边界情况。
4.2 文本文件最后一行没有换行符导致漏读
用while read读文件时，如果文件的最后一行没有换行符，部分环境下会漏读。这个问题的根源在于read是按行分隔符来判定"一行"的，没有换行符的内容读不到完整行。
解决的惯用方法是这样：
while IFS= read -r line || [ -n "$line" ]; do echo "处理: $line" done < input.txt|| [ -n "$line" ]的意思是：当read因为EOF退出时，如果line里还有内容，说明这是最后一段没有换行符的数据，也要处理。这个细节解决了很多脚本"最后一条数据丢失"的诡异现象，属于那种查了半天查不出来、最后发现是换行符问题的情况。
4.3 管道子Shell导致的变量丢失
这个坑我会重点提醒，因为它太容易踩了。先看一段"看起来没问题"的代码：
count=0 cat server.list | while read ip; do count=$((count+1)) done echo "共处理 $count 台服务器"很多人以为会输出服务器的数量，实际输出是0。原因在于管道两侧是在子Shell里执行的。整个while循环在子进程里跑，循环里对count的修改，只存在于那个子进程的内存空间中。循环结束，子进程销毁，count还是原来的0。
最常见解法是用进程替换，让while在当前Shell里执行：
count=0 while read ip; do count=$((count+1)) done < <(cat server.list) echo "共处理 $count 台服务器"< <(cat server.list)是对< server.list的推广——如果数据来源不是一个文件，而是一条命令的输出，就用进程替换来避免子Shell问题。这个解法的好处是：循环内外的变量数据共享，代码修改最小。
另一个思路是启用lastpipe选项，但这个选项只在作业控制关闭的非交互Shell里生效，可移植性不如进程替换。
4.4 性能陷阱：循环次数多的时候，怎么提速
Shell循环的处理效率远低于其他语言，这几乎是所有Shell脚本性能问题的天花板。如果只是几百上千次迭代，体验不明显；一旦进入几万、几十万的量级，慢得让人抓狂。这时候你要优先考虑的不是优化循环语法，而是减少循环本身。
能交给awk处理的，就交给awk。比如对文件的每一行做字段提取与统计，awk一次搞定，不要去写while循环：
# 低效 while read line; do ip=$(echo "$line" | awk '{print $1}') cnt=$((cnt+1)) done < file.log # 高效 awk '{print $1; count++} END {print count}' file.log能批量处理的，就不要一条条跑命令。比如要复制100个文件，与其在循环里跑100次cp，不如用一次tar或rsync批量完成。
如果你确实需要在循环内部执行不可拆分的命令，能减少循环次数的先减少次数。比如先过滤再循环，不要让循环负责过滤：
# 低效：每行都跑一次grep while read line; do if echo "$line" | grep -q "ERROR"; then ... fi done < app.log # 高效：先过滤，再处理 grep "ERROR" app.log | while read line; do ... done注意，上面第二个写法里的while又在子Shell里了。如果循环体内需要更新外部变量，改回进程替换写法即可。逻辑优先还是性能优先，由实际需求决定。
5. 从会写到用好：工程化思维与进阶工具
5.1 循环里的错误处理与超时控制
循环进入实际问题场景后，第一件事就是要处理"循环体执行失败"的情况。裸跑的循环，一旦中间某一步出错，可能脚本继续往下跑，最终留下残缺的数据。合理的做法是在循环体内检查退出码：
for dir in */; do cd "$dir" || { echo "无法进入 $dir，跳过" continue } echo "开始处理 $dir" cd .. done||后面接continue，表示进入不了目录就跳过当前迭代。这是一个很实用的模式：任何可能失败的命令，都用||接上失败后的处理分支。只有当业务上确实允许"失败可忽略"时，才什么都不写。
超时控制也是循环脚本不可忽视的一环。比如用while轮询一个接口，必须设一个最大等待时间，防止脚本无限空转：
timeout=30 elapsed=0 while ! curl -s http://127.0.0.1:8080/health; do if [ $elapsed -ge $timeout ]; then echo "等待超时，退出" exit 1 fi sleep 2 elapsed=$((elapsed+2)) done这里用elapsed变量累加等待时间，达到阈值就主动退出。很多线上事故，就是没有这类保护，脚本挂在某个细节上跑了一整夜。
5.2 进度显示与日志记录
循环跑很久的时候，如果没有输出，人根本不知道脚本卡在哪里还是正常运行中。我给循环加进度信息的原则是：每处理一个单位，输出一行简短状态，并写到日志文件。
logfile="batch_$(date +%Y%m%d).log" index=0 total=$(ls files/*.tar | wc -l) for archive in files/*.tar; do index=$((index+1)) echo "[$index/$total] 处理 $archive ..." | tee -a "$logfile" tar -xf "$archive" -C /data/unpacked/ || { echo " [错误] $archive 解压失败" | tee -a "$logfile" } done echo "全部完成，日志: $logfile"tee -a同时把信息打到屏幕和日志文件，方便实时观察，也留底。我在写超过几分钟的循环任务时，一定会加上这个机制。不然一旦脚本半夜报错，你两眼一抹黑，只能从头再来。
5.3 并行化思路：让循环利用多核能力
Shell循环默认是单线程的，处理一批互相独立的任务时，浪费了多核处理器的能力。最简单的并行化手段是使用后台任务加wait：
for server in $(cat server.list); do ssh user@$server "uptime" & done wait echo "所有服务器查询完成"&把每个任务丢到后台，wait等待所有后台任务结束。这样SSH的耗时就不再是累加的，而是并发执行。
但直接这样写有一个隐患：如果任务数量非常大（比如几百个），同时启动几百个后台进程会导致系统负载飙升。这时候要控制并发数。一个常见的做法是用"令牌"思想——用一个队列文件控制同时最多跑几个：
max_jobs=10 for task in $(cat jobs.list); do # 当前后台任务数达到上限时，等待任意一个完成 while [ $(jobs -r | wc -l) -ge $max_jobs ]; do sleep 1 done do_work "$task" & done wait echo "全部完成"jobs -r统计当前正在运行的后台任务数，达到阈值就先等待。这个方式很好理解，缺点是sleep 1的粒度不够精细。更稳的方案可以用xargs -P：
cat jobs.list | xargs -P 10 -I {} do_work {}xargs -P 10直接控制并发10个进程，代码更短，也没有睡眠轮询的问题。所以我给的建议是：小任务量用&加wait，大任务量优先考虑xargs -P。实际项目里，能用xargs -P解决的不要自己造轮子。
5.4 从循环到xargs与awk的思维升级
到这里，你基本已经能写出健壮的循环脚本了。但我建议你也留意一条升级路径：能用管道组合命令时，优先考虑替代循环的写法。我见过很多脚本，明明一行find加xargs解决的事情，非要写十行for循环，性能和可读性都吃亏。
一个典型的对比：批量删除.tmp文件。
循环写法：
for f in *.tmp; do rm "$f" done一行替代：
find . -name "*.tmp" -delete另一个例子：从文件里提取所有失败的IP并去重。
循环写法要好几行，用管道则是：
grep "FAIL" app.log | awk '{print $1}' | sort -u这不是说循环没有用，而是说循环应该用在"真的要处理每一个对象、每一步都有独立逻辑"的场景。当任务只是一个"过滤+变换+聚合"的流水线时，管道本身就是一种更高层的循环。
我自己的习惯是：写循环之前，先停下来想想这个任务能不能用一个管道解决。如果不能，再把循环拿出来。这个思考三秒钟的步骤，长期来看能帮你省下无数调试时间。
对我们这些天天和Shell打交道的人来说，循环编程的水平基本决定了脚本的可靠程度。语法本身并不复杂，真正拉开差距的是对细节的把控——通配符的展开规则、子Shell的变量隔离、文件名的特殊字符处理、循环退出条件的边界。这些年写脚本踩过的坑，几乎都集中在这些细节里。我分享的这些经验，如果能帮你在调试时少掉几根头发，这篇就没白写。后面你碰到奇怪的循环行为，也可以顺着这几种坑的方向去排查，多半能定位到问题。
