这可能是Linux命令行里被问得最多的小问题之一。写shell脚本的人十个有八个都遇到过判断某个变量里有没有包含一段子字符串。面试题里爱考实际写脚本也绕不过去。今天我就把这道题的几类解法从头到尾捋一遍包括每个方法的原理、适用场景、兼容性边界以及我踩过的那些坑。先说结论如果你用的是bash最省事、最不容易出错的是双中括号加通配符的写法。如果你写的是POSIX sh脚本就得用case或者外部命令兜底。下面我一个个拆开来讲。1. 需求场景与方案总览1.1 字符串包含判断到底在解决什么问题字符串包含判断本质上是确认一个字符串中的字符序列是否是另一个字符串的连续子串。比如变量str的值是hello-world我们要判断它是否包含world或者判断文件名是否以某个前缀开头、以某个后缀结尾这些都是同一个问题的变体。这类需求在实际脚本里出现频率极高。我见过最典型的几种场景判断当前的系统发行版信息决定走哪条安装分支。比如检测到IDdebian就走apt检测到IDcentos就走yum。校验用户输入。比如让用户输入yes或y表示确认你就需要判断输入字符串是否包含关键字。批量文件处理。遍历目录下所有文件检查文件名是否包含指定关键词再做移动或重命名操作。日志关键字监控。读取日志内容判断是否出现ERROR或Exception触发告警或重启服务。在这些场景里一个可靠的字符串包含判断方法直接决定了脚本的稳定性。1.2 五类主流方案一图看清我先把常用的方案列个表后面逐个展开细讲。方案核心写法环境依赖推荐指数bash双中括号通配符[[ $str *sub* ]]bash/zsh/ksh五星case语句模式匹配case $str in *sub*) ;; esacPOSIX兼容五星grep外部命令grep -q sub $str需grep四星expr命令匹配expr $str : .*sub需expr三星awk文本处理awk -v s$str BEGIN{...}需awk三星实际项目里我95%的情况都用前两种。但如果要处理跨平台或需要极致性能后三种也有它们的位置。接下来我会把每种方法的原理和执行细节都过一遍。2. 最常用的内建语法双中括号通配符匹配2.1 通配符匹配机制是怎么运作的bash的双中括号[[ ]]是一个内置的复合命令它对右侧的表达式做模式匹配而不是直接做字符串相等比较。当你在右侧写上*sub*的时候星号*表示任意长度的任意字符命令行表达式就等价于“字符串中任何位置出现了sub这个连续片段就算匹配成功”。基本写法是这样的strhello-world if [[ $str *world* ]]; then echo 包含 world else echo 不包含 world fi这段脚本在bash下会输出包含 world。关键是右侧两个星号分别放在了子字符串的前面和后面表示允许world前面和后面有任意字符。如果你只写$str world那就是判断整个字符串完全等于world含义完全不一样别搞混了。需要注意[[ ]]里的模式匹配不是正则表达式。*代表任意多个字符?代表任意一个字符[...]代表字符集。这些是通配符规则也叫glob pattern。很多人第一次用的时候会把、^这些正则符号往里写结果发现不生效就是没搞清楚这个区别。还有一个容易忽略的点匹配模式如果包含特殊通配符字符而你只想做纯文本判断就必须把子字符串放进引号里比如*sub*。加了引号之后sub里的*、?、[都会被当作普通字符处理。这是官方手册里明确写的规则也是判断是否包含“字面文本”的标准做法。2.2 变量为空、引号遗漏与正则转义的连环坑下面这几个坑我基本都在生产环境里踩过。每一个都值得单独拿出来说。第一个坑是变量为空的情况。[[ ]]在模式一侧是不需要加引号的但变量一侧最好加上引号否则变量为空时会语法报错。比如str if [[ $str *world* ]]; then echo 包含 fi因为str为空[[ $str ... ]]会变成[[ *world* ]]这行命令直接语法错误。正确的写法是[[ $str *world* ]]。我见过不少刚写脚本的同学在这里栽跟头报错信息还看不明白。第二个坑是子字符串本身带有通配符或正则符号。假设你要判断URL是否包含https://example.com?a1b2这里面的?和*如果不处理会被当成通配符解释。安全稳妥的写法是if [[ $url *https://example.com?a1b2* ]]; then echo 匹配 fi我把整个子字符串放在双引号里通配符解析就对它完全失效了。第三个坑是大小写敏感问题。默认情况下[[ ]]的模式匹配是区分的。world和World是两个东西。如果你要做大小写不敏感的包含判断可以用shopt -s nocasematch打开bash的忽略大小写开关或者用tr转换后比较。shopt -s nocasematch if [[ $str *world* ]]; then echo 不区分大小写匹配 fi shopt -u nocasematch用完了记得关掉不然会影响后面所有字符串判断逻辑。第四个坑是[[ ]]只能用在bash、zsh、ksh这类增强版shell里在dash和纯POSIX sh环境下运行会直接报[[: not found。如果你写的是系统初始化脚本比如Debian的/bin/sh实际指向dash就必须换用下面的case方案。3. 兼容POSIX的经典姿势case与外部命令3.1 用case语句写出可移植的包含判断/bin/sh是POSIX标准shell很多系统脚本都用它做解释器。在sh环境下[[ ]]不可用但case语句是POSIX规范明确规定的语法天然支持模式匹配所以在sh里判断字符串包含case是第一选择。写法如下strhello-world case $str in *world*) echo 包含 world ;; *) echo 不包含 world ;; esac这个写法的逻辑和[[ ]]完全一致都是靠*通配符来匹配任意字符。case语句里同样可以使用?和[...]配合起来可以写出非常灵活的模式组合。case的好处不只是兼容性好还因为它是shell内建语法不需要启动外部进程性能在脚本循环场景下非常可观。而且case天然支持“多条件分支”判断一个字符串同时包含多个子串时可以直接罗列多个模式比如case $str in *error*|*fail*) echo 检测到异常关键词 ;; *success*) echo 检测到成功关键词 ;; esac注意竖线|在case里是“或”的意思整个模式列表只要命中其中一个就进入对应分支。这个特性在日志告警脚本里非常实用一个case就能代替多个if判断可读性也更好。3.2 grep、expr在管道场景中的使用细节如果你的脚本环境里有grep用grep做包含判断也是一种很常见的做法尤其是手写命令行临时判断时很顺手if echo $str | grep -q world; then echo 包含 fi-q参数是安静模式不输出匹配内容只返回退出状态码。这样写的好处是支持正则表达式可以匹配更复杂的模式比如判断是否包含数字、邮箱格式等。但在循环里频繁调用grep会导致性能下降因为每次调用都会启动一个新进程。脚本里遍历几百个文件时这个开销会非常明显。比echo | grep更优雅一点的写法是用heredocif grep -q world $str; then echo 包含 fi这条命令用了here-string把字符串直接通过标准输入传给grep不需要echo也不会出现换行符干扰。我在交互式命令行里特别喜欢这么写。如果你需要判断子字符串在原字符串中的位置可以用expr indexpos$(expr index $str world)expr index返回的是字符在字符串中第一次出现的位置从1开始注意它是逐个字符匹配的不是子字符串整体匹配。比如expr index hello world会返回2因为它找到了h不是它实际是找hello中任意一个字符首次出现的位置h在位置1所以返回1。想整体查找子字符串位置应该用expr match或者用字符串运算pos$(expr match $str .*world)不过这种方式返回的是匹配的完整长度并不是直观的起始位置实际项目里我很少依赖它。更常见的是用POSIX sh的${var%%...}和${var%...}做后缀判断用${var##...}和${var#...}做前缀判断配合${var%...*}的形状能达到包含判断的效果。if [ $str ! ${str#*world} ]; then echo 包含 world fi这个方法的原理是如果str包含world那么删除最短前缀匹配后的结果一定和原str不同。这个技巧不依赖bash特性也是POSIX兼容的适合在sh脚本里做快速判断。3.3 awk处理复杂文本时的替代思路awk在文本处理领域的地位不用多说判断字符串包含也能用它。最典型的写法if awk -v s$str BEGIN { if (index(s, world) 0) exit 0; else exit 1 }; then echo 包含 fiindex(s, world)会返回子字符串在s中第一次出现的位置找不到就返回0。用awk处理的优势是如果你需要对日志文件的内容做逐行扫描且没装grepawk的可用性非常高。它还能顺带处理字段切割比如提取时间戳、严重级别等在复杂日志场景里比单纯grep更灵活。不过awk方案的问题也很明显启动开销大代码晦涩对初学者不友好。大多数场景下你完全可以用case或[[ ]]解决所以awk这个方案我一般放在压轴位只有遇到“既要包含判断又需要按分隔符拆字段”的复合需求时才写。4. 多条件组合与真实场景实践4.1 数组遍历与批量文件校验中的包含判断实战环节我先用最常见的“批量处理文件名”场景练手。假设目录/data/logs下有大量日志文件需要找出文件名既包含access又包含2024的文件把它们归档到/data/archive。#!/bin/bash input_dir/data/logs output_dir/data/archive mkdir -p $output_dir for file in $input_dir/*; do name$(basename $file) if [[ $name *access* $name *2024* ]]; then mv $file $output_dir/ fi done这里一个细节值得注意我在[[ ]]里写的是而不是-a。初学者在[ ]里习惯用-a但双中括号里才是推荐的写法逻辑更清晰也避免了-a在某些环境下行为不一致的坑。如果脚本需要跑在sh上同一个需求用case叠加匹配的话可以两次case嵌套也可以一次case模式引用变量但嵌套的方式可读性更好case $name in *access*) case $name in *2024*) mv $file $output_dir/ ;; esac ;; esac嵌套case的逻辑直观易懂而且每一层匹配都有明确的缩进分隔多人协作时不会产生歧义。批量文件场景里还有一个高频需求判断文件名是否以.tar.gz或.zip结尾。用[[ ]]可以这样写if [[ $name *.tar.gz || $name *.zip ]]; then echo 这是一个压缩包 fi这里的*.tar.gz没有给tar.gz加引号因为这里就是要用通配符语法。如果加了引号反而成了字面匹配*.tar.gz逻辑就反了。使用[[ ]]时引号位置的取舍一定要根据场景来这不是一个“无脑加引号”的问题。4.2 参数解析与日志监控中的包含判断参数解析也是包含判断的重灾区。比如一个安装脚本要解析用户的安装模式参数--modexxx判断参数里是否包含--modefor arg in $; do case $arg in --mode*) mode${arg#--mode} echo 安装模式: $mode ;; --*) echo 未知参数: $arg ;; esac done${arg#--mode}这个写法是POSIX参数扩展表示删除开头匹配--mode的部分剩下的就是真正的值。配合case的--mode*前缀匹配一个循环就能干净地解析出选项值完全没用到[[ ]]在任何sh环境都能跑。日志监控场景我举一个真实例子。某运维流程里有一个服务健康检查脚本需要判断进程输出里是否包含listen on port 8080字样如果包含就认为启动成功否则等待重试attempt0 while [ $attempt -lt 30 ]; do output$(curl -s http://127.0.0.1:8080/health 2/dev/null) if [[ $output *ok* ]]; then echo 服务就绪 exit 0 fi attempt$((attempt 1)) sleep 2 done echo 服务启动超时 exit 1这里的判断逻辑简单但执行环境可能是容器镜像基础镜像里可能只有sh没有bash那么把[[ ]]换成case即可case $output in *ok*) echo 服务就绪; exit 0 ;; esac这种从命令行到脚本、从bash到sh的迁移门槛正是掌握case方案最大的价值。4.3 结合回显与退出码的控制流设计判断完字符串包含之后脚本里往往还要做后续动作。一个容易被忽略的点是退出码的使用。如果你用grep方案grep的退出码已经表达了匹配结果直接用它作为脚本的返回值也很常见echo $output | grep -q ERROR if [ $? -eq 0 ]; then echo 发现错误日志 else echo 日志正常 fi但更好的做法是不依赖$?直接在if里判断grep的返回值if echo $output | grep -q ERROR; then echo 发现错误日志 fi这样写更简洁而且不会因为中间插入了别的命令导致$?被覆盖。这也是我在Code Review时经常给团队小伙伴提的一条建议。5. 性能对比与脚本避坑速查5.1 循环场景下的性能实测字符串包含判断本身是个高频操作如果出现在大的循环里性能差异会被放大。我自己用一个简单的循环做了对比测试循环10万次分别调用[[ ]]、case、grep、expr四种方式判断一个固定字符串是否包含子串。方法10万次耗时备注[[ $s *sub* ]]约0.3秒纯内建不启动外部进程case模式匹配约0.3秒纯内建性能同上grep -q约8秒以上每次启动一个进程开销大expr match约6秒以上同样依赖外部命令实测结果非常清晰纯内建的写法比外部命令快一个数量级。这不是说grep就不能用单次判断时那点开销根本感知不到但一旦进入循环、批量处理的场景内建语法就体现出压倒性优势了。所以我的建议是命令行随手判断用grep无所谓系统脚本和循环逻辑里优先用[[ ]]或case。5.2 特殊字符、空值与返回值陷阱速查这个主题下常见的坑我汇总成了一张表方便你查阅陷阱场景现象解决方案变量为空且没加引号[[ ]]报语法错误变量侧统一加双引号子串含*、?等通配符匹配结果与预期不符子串放入双引号内需要忽略大小写匹配不到大写变体使用shopt -s nocasematch在/bin/sh里写[[报[[: not found改用case或POSIX参数扩展循环里用grep脚本变慢换成内建判断减少fork进程判断前缀/后缀时误写**吞掉过多字符只写需要的通配符别随手多写字符串含换行或特殊符号输出结果混乱优先用[[ ]]和case避免echo干扰还有一个小技巧值得分享判断字符串是否“不包含”某个子串用[[ $s ! *sub* ]]即可。很多人会写成! [[ $s *sub* ]]语法也能过但前者读起来顺畅得多。5.3 一条快速经验清单说了一堆方法和坑位最后给一条可以立刻上手的经验清单默认使用[[ $var *sub* ]]简单直接覆盖80%场景。需要兼容/bin/sh时改用case或[ $var ! ${var#*sub} ]。子字符串含正则符号时必须加引号包裹。只用做临时人工判断时直接用grep -q无可厚非。循环量大时不要用任何外部命令方案。注意大小写问题如果业务场景不分大小写明确开启nocasematch或者统一转换大小写之后再判断。最后再分享一个我在实际运维中总结的经验字符串包含判断看似只是一个小知识点但它牵涉到shell语法兼容性、性能模型、通配符与正则的区别等多个维度。把这些底层逻辑搞清楚之后再去处理复杂的参数解析和日志匹配思路会清晰很多脚本出问题的概率也直线下降。写shell脚本这种事不怕问题小就怕原理不清。希望这篇内容能帮你把这一块彻底拿稳。 
长河君 · 2026/10/16 2:39:28 · 阅读 1.2k Linux Shell字符串包含判断：5种实现方案与避坑指南
这可能是Linux命令行里被问得最多的小问题之一。写shell脚本的人十个有八个都遇到过判断某个变量里有没有包含一段子字符串。面试题里爱考实际写脚本也绕不过去。今天我就把这道题的几类解法从头到尾捋一遍包括每个方法的原理、适用场景、兼容性边界以及我踩过的那些坑。先说结论如果你用的是bash最省事、最不容易出错的是双中括号加通配符的写法。如果你写的是POSIX sh脚本就得用case或者外部命令兜底。下面我一个个拆开来讲。1. 需求场景与方案总览1.1 字符串包含判断到底在解决什么问题字符串包含判断本质上是确认一个字符串中的字符序列是否是另一个字符串的连续子串。比如变量str的值是hello-world我们要判断它是否包含world或者判断文件名是否以某个前缀开头、以某个后缀结尾这些都是同一个问题的变体。这类需求在实际脚本里出现频率极高。我见过最典型的几种场景判断当前的系统发行版信息决定走哪条安装分支。比如检测到IDdebian就走apt检测到IDcentos就走yum。校验用户输入。比如让用户输入yes或y表示确认你就需要判断输入字符串是否包含关键字。批量文件处理。遍历目录下所有文件检查文件名是否包含指定关键词再做移动或重命名操作。日志关键字监控。读取日志内容判断是否出现ERROR或Exception触发告警或重启服务。在这些场景里一个可靠的字符串包含判断方法直接决定了脚本的稳定性。1.2 五类主流方案一图看清我先把常用的方案列个表后面逐个展开细讲。方案核心写法环境依赖推荐指数bash双中括号通配符[[ $str *sub* ]]bash/zsh/ksh五星case语句模式匹配case $str in *sub*) ;; esacPOSIX兼容五星grep外部命令grep -q sub $str需grep四星expr命令匹配expr $str : .*sub需expr三星awk文本处理awk -v s$str BEGIN{...}需awk三星实际项目里我95%的情况都用前两种。但如果要处理跨平台或需要极致性能后三种也有它们的位置。接下来我会把每种方法的原理和执行细节都过一遍。2. 最常用的内建语法双中括号通配符匹配2.1 通配符匹配机制是怎么运作的bash的双中括号[[ ]]是一个内置的复合命令它对右侧的表达式做模式匹配而不是直接做字符串相等比较。当你在右侧写上*sub*的时候星号*表示任意长度的任意字符命令行表达式就等价于“字符串中任何位置出现了sub这个连续片段就算匹配成功”。基本写法是这样的strhello-world if [[ $str *world* ]]; then echo 包含 world else echo 不包含 world fi这段脚本在bash下会输出包含 world。关键是右侧两个星号分别放在了子字符串的前面和后面表示允许world前面和后面有任意字符。如果你只写$str world那就是判断整个字符串完全等于world含义完全不一样别搞混了。需要注意[[ ]]里的模式匹配不是正则表达式。*代表任意多个字符?代表任意一个字符[...]代表字符集。这些是通配符规则也叫glob pattern。很多人第一次用的时候会把、^这些正则符号往里写结果发现不生效就是没搞清楚这个区别。还有一个容易忽略的点匹配模式如果包含特殊通配符字符而你只想做纯文本判断就必须把子字符串放进引号里比如*sub*。加了引号之后sub里的*、?、[都会被当作普通字符处理。这是官方手册里明确写的规则也是判断是否包含“字面文本”的标准做法。2.2 变量为空、引号遗漏与正则转义的连环坑下面这几个坑我基本都在生产环境里踩过。每一个都值得单独拿出来说。第一个坑是变量为空的情况。[[ ]]在模式一侧是不需要加引号的但变量一侧最好加上引号否则变量为空时会语法报错。比如str if [[ $str *world* ]]; then echo 包含 fi因为str为空[[ $str ... ]]会变成[[ *world* ]]这行命令直接语法错误。正确的写法是[[ $str *world* ]]。我见过不少刚写脚本的同学在这里栽跟头报错信息还看不明白。第二个坑是子字符串本身带有通配符或正则符号。假设你要判断URL是否包含https://example.com?a1b2这里面的?和*如果不处理会被当成通配符解释。安全稳妥的写法是if [[ $url *https://example.com?a1b2* ]]; then echo 匹配 fi我把整个子字符串放在双引号里通配符解析就对它完全失效了。第三个坑是大小写敏感问题。默认情况下[[ ]]的模式匹配是区分的。world和World是两个东西。如果你要做大小写不敏感的包含判断可以用shopt -s nocasematch打开bash的忽略大小写开关或者用tr转换后比较。shopt -s nocasematch if [[ $str *world* ]]; then echo 不区分大小写匹配 fi shopt -u nocasematch用完了记得关掉不然会影响后面所有字符串判断逻辑。第四个坑是[[ ]]只能用在bash、zsh、ksh这类增强版shell里在dash和纯POSIX sh环境下运行会直接报[[: not found。如果你写的是系统初始化脚本比如Debian的/bin/sh实际指向dash就必须换用下面的case方案。3. 兼容POSIX的经典姿势case与外部命令3.1 用case语句写出可移植的包含判断/bin/sh是POSIX标准shell很多系统脚本都用它做解释器。在sh环境下[[ ]]不可用但case语句是POSIX规范明确规定的语法天然支持模式匹配所以在sh里判断字符串包含case是第一选择。写法如下strhello-world case $str in *world*) echo 包含 world ;; *) echo 不包含 world ;; esac这个写法的逻辑和[[ ]]完全一致都是靠*通配符来匹配任意字符。case语句里同样可以使用?和[...]配合起来可以写出非常灵活的模式组合。case的好处不只是兼容性好还因为它是shell内建语法不需要启动外部进程性能在脚本循环场景下非常可观。而且case天然支持“多条件分支”判断一个字符串同时包含多个子串时可以直接罗列多个模式比如case $str in *error*|*fail*) echo 检测到异常关键词 ;; *success*) echo 检测到成功关键词 ;; esac注意竖线|在case里是“或”的意思整个模式列表只要命中其中一个就进入对应分支。这个特性在日志告警脚本里非常实用一个case就能代替多个if判断可读性也更好。3.2 grep、expr在管道场景中的使用细节如果你的脚本环境里有grep用grep做包含判断也是一种很常见的做法尤其是手写命令行临时判断时很顺手if echo $str | grep -q world; then echo 包含 fi-q参数是安静模式不输出匹配内容只返回退出状态码。这样写的好处是支持正则表达式可以匹配更复杂的模式比如判断是否包含数字、邮箱格式等。但在循环里频繁调用grep会导致性能下降因为每次调用都会启动一个新进程。脚本里遍历几百个文件时这个开销会非常明显。比echo | grep更优雅一点的写法是用heredocif grep -q world $str; then echo 包含 fi这条命令用了here-string把字符串直接通过标准输入传给grep不需要echo也不会出现换行符干扰。我在交互式命令行里特别喜欢这么写。如果你需要判断子字符串在原字符串中的位置可以用expr indexpos$(expr index $str world)expr index返回的是字符在字符串中第一次出现的位置从1开始注意它是逐个字符匹配的不是子字符串整体匹配。比如expr index hello world会返回2因为它找到了h不是它实际是找hello中任意一个字符首次出现的位置h在位置1所以返回1。想整体查找子字符串位置应该用expr match或者用字符串运算pos$(expr match $str .*world)不过这种方式返回的是匹配的完整长度并不是直观的起始位置实际项目里我很少依赖它。更常见的是用POSIX sh的${var%%...}和${var%...}做后缀判断用${var##...}和${var#...}做前缀判断配合${var%...*}的形状能达到包含判断的效果。if [ $str ! ${str#*world} ]; then echo 包含 world fi这个方法的原理是如果str包含world那么删除最短前缀匹配后的结果一定和原str不同。这个技巧不依赖bash特性也是POSIX兼容的适合在sh脚本里做快速判断。3.3 awk处理复杂文本时的替代思路awk在文本处理领域的地位不用多说判断字符串包含也能用它。最典型的写法if awk -v s$str BEGIN { if (index(s, world) 0) exit 0; else exit 1 }; then echo 包含 fiindex(s, world)会返回子字符串在s中第一次出现的位置找不到就返回0。用awk处理的优势是如果你需要对日志文件的内容做逐行扫描且没装grepawk的可用性非常高。它还能顺带处理字段切割比如提取时间戳、严重级别等在复杂日志场景里比单纯grep更灵活。不过awk方案的问题也很明显启动开销大代码晦涩对初学者不友好。大多数场景下你完全可以用case或[[ ]]解决所以awk这个方案我一般放在压轴位只有遇到“既要包含判断又需要按分隔符拆字段”的复合需求时才写。4. 多条件组合与真实场景实践4.1 数组遍历与批量文件校验中的包含判断实战环节我先用最常见的“批量处理文件名”场景练手。假设目录/data/logs下有大量日志文件需要找出文件名既包含access又包含2024的文件把它们归档到/data/archive。#!/bin/bash input_dir/data/logs output_dir/data/archive mkdir -p $output_dir for file in $input_dir/*; do name$(basename $file) if [[ $name *access* $name *2024* ]]; then mv $file $output_dir/ fi done这里一个细节值得注意我在[[ ]]里写的是而不是-a。初学者在[ ]里习惯用-a但双中括号里才是推荐的写法逻辑更清晰也避免了-a在某些环境下行为不一致的坑。如果脚本需要跑在sh上同一个需求用case叠加匹配的话可以两次case嵌套也可以一次case模式引用变量但嵌套的方式可读性更好case $name in *access*) case $name in *2024*) mv $file $output_dir/ ;; esac ;; esac嵌套case的逻辑直观易懂而且每一层匹配都有明确的缩进分隔多人协作时不会产生歧义。批量文件场景里还有一个高频需求判断文件名是否以.tar.gz或.zip结尾。用[[ ]]可以这样写if [[ $name *.tar.gz || $name *.zip ]]; then echo 这是一个压缩包 fi这里的*.tar.gz没有给tar.gz加引号因为这里就是要用通配符语法。如果加了引号反而成了字面匹配*.tar.gz逻辑就反了。使用[[ ]]时引号位置的取舍一定要根据场景来这不是一个“无脑加引号”的问题。4.2 参数解析与日志监控中的包含判断参数解析也是包含判断的重灾区。比如一个安装脚本要解析用户的安装模式参数--modexxx判断参数里是否包含--modefor arg in $; do case $arg in --mode*) mode${arg#--mode} echo 安装模式: $mode ;; --*) echo 未知参数: $arg ;; esac done${arg#--mode}这个写法是POSIX参数扩展表示删除开头匹配--mode的部分剩下的就是真正的值。配合case的--mode*前缀匹配一个循环就能干净地解析出选项值完全没用到[[ ]]在任何sh环境都能跑。日志监控场景我举一个真实例子。某运维流程里有一个服务健康检查脚本需要判断进程输出里是否包含listen on port 8080字样如果包含就认为启动成功否则等待重试attempt0 while [ $attempt -lt 30 ]; do output$(curl -s http://127.0.0.1:8080/health 2/dev/null) if [[ $output *ok* ]]; then echo 服务就绪 exit 0 fi attempt$((attempt 1)) sleep 2 done echo 服务启动超时 exit 1这里的判断逻辑简单但执行环境可能是容器镜像基础镜像里可能只有sh没有bash那么把[[ ]]换成case即可case $output in *ok*) echo 服务就绪; exit 0 ;; esac这种从命令行到脚本、从bash到sh的迁移门槛正是掌握case方案最大的价值。4.3 结合回显与退出码的控制流设计判断完字符串包含之后脚本里往往还要做后续动作。一个容易被忽略的点是退出码的使用。如果你用grep方案grep的退出码已经表达了匹配结果直接用它作为脚本的返回值也很常见echo $output | grep -q ERROR if [ $? -eq 0 ]; then echo 发现错误日志 else echo 日志正常 fi但更好的做法是不依赖$?直接在if里判断grep的返回值if echo $output | grep -q ERROR; then echo 发现错误日志 fi这样写更简洁而且不会因为中间插入了别的命令导致$?被覆盖。这也是我在Code Review时经常给团队小伙伴提的一条建议。5. 性能对比与脚本避坑速查5.1 循环场景下的性能实测字符串包含判断本身是个高频操作如果出现在大的循环里性能差异会被放大。我自己用一个简单的循环做了对比测试循环10万次分别调用[[ ]]、case、grep、expr四种方式判断一个固定字符串是否包含子串。方法10万次耗时备注[[ $s *sub* ]]约0.3秒纯内建不启动外部进程case模式匹配约0.3秒纯内建性能同上grep -q约8秒以上每次启动一个进程开销大expr match约6秒以上同样依赖外部命令实测结果非常清晰纯内建的写法比外部命令快一个数量级。这不是说grep就不能用单次判断时那点开销根本感知不到但一旦进入循环、批量处理的场景内建语法就体现出压倒性优势了。所以我的建议是命令行随手判断用grep无所谓系统脚本和循环逻辑里优先用[[ ]]或case。5.2 特殊字符、空值与返回值陷阱速查这个主题下常见的坑我汇总成了一张表方便你查阅陷阱场景现象解决方案变量为空且没加引号[[ ]]报语法错误变量侧统一加双引号子串含*、?等通配符匹配结果与预期不符子串放入双引号内需要忽略大小写匹配不到大写变体使用shopt -s nocasematch在/bin/sh里写[[报[[: not found改用case或POSIX参数扩展循环里用grep脚本变慢换成内建判断减少fork进程判断前缀/后缀时误写**吞掉过多字符只写需要的通配符别随手多写字符串含换行或特殊符号输出结果混乱优先用[[ ]]和case避免echo干扰还有一个小技巧值得分享判断字符串是否“不包含”某个子串用[[ $s ! *sub* ]]即可。很多人会写成! [[ $s *sub* ]]语法也能过但前者读起来顺畅得多。5.3 一条快速经验清单说了一堆方法和坑位最后给一条可以立刻上手的经验清单默认使用[[ $var *sub* ]]简单直接覆盖80%场景。需要兼容/bin/sh时改用case或[ $var ! ${var#*sub} ]。子字符串含正则符号时必须加引号包裹。只用做临时人工判断时直接用grep -q无可厚非。循环量大时不要用任何外部命令方案。注意大小写问题如果业务场景不分大小写明确开启nocasematch或者统一转换大小写之后再判断。最后再分享一个我在实际运维中总结的经验字符串包含判断看似只是一个小知识点但它牵涉到shell语法兼容性、性能模型、通配符与正则的区别等多个维度。把这些底层逻辑搞清楚之后再去处理复杂的参数解析和日志匹配思路会清晰很多脚本出问题的概率也直线下降。写shell脚本这种事不怕问题小就怕原理不清。希望这篇内容能帮你把这一块彻底拿稳。