那段时间我接手了一个日志分析的小任务要在几百万行nginx日志里找出某个接口的响应时间异常飙升的case。起初我打算用编辑器打开慢慢找被同事一句你居然不用grep和awk是不是对Shell有什么误解给激到了。也正是从那次开始我才真正把正则表达式和文本处理器三件套grep、sed、awk用熟从此日志分析、配置批量修改、报表统计这些活儿基本都交给了Shell脚本。这篇东西我就按自己的实战路径来写谈谈正则表达式在Shell语境下怎么学、文本处理器怎么分工、有哪些坑我替你先踩了。先说个总的认识正则表达式和文本处理器在Shell里不是分开学的它们是同一个工作流的上下游。正则负责描述你要找什么grep负责把匹配的行挑出来sed负责挑出来之后再改一改awk负责把改好的内容按列拆分、统计、输出报表。四者单独拿出来都简单但一旦放进命令行管道里组合使用威力完全是另一回事。这篇文章不搞教科书式的语法大全我会用真实任务场景把每个工具的用法、原理、常见坑串起来适合刚摸到Shell门槛的入门者也适合已经会写简单脚本但总觉得文本处理不够顺手的开发者。1. 正则表达式在Shell里的方言问题先聊正则。很多人一学正则就拿着Python、JavaScript、Java那套直接往Shell里套结果排错半天最后发现是转义和规则差异的问题。Shell环境里的正则其实分三种流派基础正则表达式BRE、扩展正则表达式ERE和PCREPerl兼容正则grep -P开启。三者的区别不是名字叫得花哨而是实际写出来的符号行为和转义要求完全不同这一点是新手最容易栽跟头的第一道坎。1.1 正则的三个基本构成不管哪个流派正则的基本零件大致相同我这里用一个生活化的方式过一遍方便你建立直觉字符类[abc]匹配a、b、c中的任意一个字符[0-9]匹配任意数字。这就像你筛人的时候说只要张、李、王这三个姓氏的人。量词*表示前一个字符出现0次或多次表示出现1次或多次?表示出现0次或1次。这相当于规定这个字段可以没有也可以有但不能超过一次。锚定^匹配行首$匹配行尾。这个的作用是限定位置避免从一行中间捡漏。分组用圆括号把一段表达式包起来便于整体应用量词或者提取内容比如(ab)匹配ab、abab、ababab。转义\.匹配一个点号\\匹配一个反斜杠。它的作用是告诉引擎这里按字面符号处理不是特殊含义。这些概念在任何语言里都一样但放到Shell里你还要多考虑一层你在命令行里写的字符串先被Shell解析一遍才被正则引擎消费。这就是为什么有些模式你看着没毛病跑起来就出问题。1.2 同一套正则不同引擎的写法不互通举一个最典型的例子在BRE中和?是普通字符不具备一次或多次零次或一次的意思你要用它们就得写成\和\?。在ERE中情况反过来和?直接表示量词不需要转义。也就是说同样表示数字至少出现一次grep不带-E时得写[0-9]\带-E时写[0-9]就行。我第一次用grep [0-9]去找连续数字时发现匹配出来的结果乱七八糟一度以为是文件编码问题后来才知道是BRE和ERE在量词转义上的规矩不同。{m,n}区间量词也是同理BRE里要写\{m,n\}ERE里写{m,n}。而grep -P使用的PCRE则更接近Perl风格支持\d、\w这类简写字符类日常做解析时方便很多但它的兼容性有时候会受grep版本影响并非所有的系统的grep默认带-P。所以我个人的习惯是脚本里统一用grep -E保证可移植性遇到特别复杂的匹配才考虑-P并且我会在代码注释里标明依赖GNU grep。1.3 正则核心价值模式与数据分离理解Shell正则还有一个关键点正则的核心思维不是写死一个字符串而是抽象出一类模式。比如你要从日志里找出所有5xx状态码的行直接写 500 也行但只能匹配500写成 5[0-9][0-9] 就能覆盖500到599。这种模式抽象能力一旦建立你在处理变化中带规律的数据时会快人一等。所以不建议一上来就背几十条正则公式而是多练习把一句话需求翻译成模式的思维过程比如找出所有以error开头或结尾的行 →^error或error$找出包含IP地址的行 →([0-9]{1,3}\.){3}[0-9]{1,3}找出行首有两个空格的配置项 →^ [a-zA-Z]2. grep最通用的文本筛选工具就该这么用grep的英文全称是Global Regular Expression Print用通俗的话讲就是把匹配到的行打印出来。很多教程把它定义为查找命令但我更愿意把它理解成文本行的过滤器输入是一堆文本grep按照你给的模式决定哪些行能过关剩下的全部丢弃。这个定位很重要因为后面讲管道配合时你会发现grep更像是数据流中第一道粗筛的关卡。2.1 参数组合是grep发挥威力的关键单用grep pattern file只算入门实际脚本里几乎总是组合参数使用。我把自己日常最常用的组合整理成下面的表格方便你对照着记忆参数作用实战举例-E使用扩展正则grep -E 5[0-9][0-9] access.log-v反向匹配排除符合模式的行grep -v ^# nginx.conf去掉注释行-i忽略大小写grep -i error app.log同时匹配Error/ERROR-n输出行号grep -n password config.yml方便定位-c只输出匹配行数grep -c timeout log.txt快速统计-o只输出匹配到的部分而不是整行grep -o [0-9]\.[0-9] data.txt提取所有数字-A、-B、-C打印匹配行之后、之前、前后的上下文grep -A 2 Exception server.log看异常栈-q静默模式只返回状态码不输出任何内容在脚本条件判断中非常实用--include在目录递归搜索时限定文件类型grep -rn TODO --include*.py .这里面我想特别提一下-q。它不输出内容只通过退出状态码告诉你有没有匹配因此在Shell脚本中经常配合if使用比如if grep -q ERROR /var/log/app.log; then echo 日志中出现了ERROR需要关注 fi2.2 在脚本里用grep的细节grep在脚本中容易踩的坑我列几个亲身经历的第一个是忘记加-E却写了、?、{m,n}这类ERE量词导致匹配结果全错。这个问题前面已经说过了但值得再强调一次因为它属于表现不出来但结果完全不对的隐蔽错误。第二个是用grep -c来判断文件里是否有某个模式这其实是个误用。-c只统计行数不区分0和没有匹配——如果统计结果是一个很大数字当然没问题但如果统计结果是0它也不会返回非零的退出码因为grep的退出码只表示是否找到匹配和-c的输出是两码事。所以严谨的写法是需要数量时用-c解析输出需要判断存在性时用grep -q单独判断。第三个是匹配到的内容里带特殊字符比如括号、方括号、美元符号。处理这类问题有一招很管用用grep -F把模式当作固定字符串处理不做正则解释这是我在处理路径、URL参数时最常用的方式。比如你想在一个文件里找出所有含$APP_HOME的行直接grep -F $APP_HOME config.sh就行省去转义的心智负担。第四个是关于二进制文件。grep默认对二进制文件只输出Binary file xxx matches不打印具体内容如果你明确知道文件里有一段文本需要提取可以加-a把文件当作文本处理。但这个操作要谨慎最好先确认文件确实是含文本的混合二进制比如Java class文件里嵌了字符串否则输出全是乱码。2.3 递归搜索目录时的行为差异另外补一句grep -r在搜索目录时如果不加--include或--exclude会把目录下所有文件都扫一遍包括隐藏在.git、node_modules里的内容速度慢且结果噪音大。我的习惯是先用--include限缩文件类型必要时再加--exclude-dir排除特定目录。比如grep -rn getUserInfo --include*.java --exclude-dirtarget .这条命令曾在一次重构时帮我快速定位某个接口被调用的所有位置只搜Java源文件把编译产物和依赖包全部挡在外面。3. sed流编辑器不是只用来替换文本sed全称Stream Editor中文叫流编辑器。流这个词意味着它处理的不是整个文件而是一行接一行流过来的数据。它非常适合在管道中直接加工数据。很多人学sed只记住了s/old/new/g这一个替换命令但实际上sed能做删除、插入、改变行顺序等操作我把它定位成批量的文本编辑手术刀。3.1 核心命令速览与地址定界sed的基本调用格式是sed 地址范围命令 文件其中地址范围可以省略省略时表示处理所有行。下面是几个常用的命令s/old/new/替换每行第一个匹配到的old为new加g表示全局替换每行所有匹配都换。d删除匹配的行比如sed /^#/d删除所有注释行。p打印匹配的行通常配合-n使用sed -n 5,10p可以打印第5到第10行。a和i在匹配行后面追加或者前面插入内容。c将匹配到的行整行替换为新内容。地址定界是sed一个强大的特色。行号、正则、步进都能用来定位地址# 删除第3到第5行 sed 3,5d data.txt # 从含BEGIN的那一行开始到含END的那一行结束删除这中间的所有行 sed /BEGIN/,/END/d data.txt # 对第2行开始每隔3行做一次替换 sed 2~3s/foo/bar/ data.txt这个正则与行号结合的地址定界方式在清洗配置文件、截取日志片段时非常省事。有一回我需要提取某个事务日志里从Transaction Start到Transaction End之间的所有内容直接一条sed -n /Transaction Start/,/Transaction End/p就搞定了连脚本循环都省了。3.2 实战案例一批量修改配置文件假设你的项目里有几十个properties文件里面写着server.port8080现在要把端口统一改成8090。用编辑器一个个改显然很低效sed一行就完成sed -i s/server\.port8080/server.port8090/ config/*.properties注意几点-i表示原地修改GNU sed里直接生效BSD sed要求-i 这里给模式加了\.转义是因为点号在正则里能匹配任意字符不转义的话连serverXport8080这种数据也会被误匹配。先用sed s/.../.../不带-i做一次预览确认无误后再加-i是我一贯的保险做法毕竟原地改文件是不可逆操作。3.3 实战案例二日志清洗与字段提取sed在管道里处理流式数据时也很顺手。比如应用日志里每一行都是这种格式2026-05-12 10:33:45 INFO request_id12345 user_id9876 path/api/login status200 cost120ms你只想留下时间、用户ID、路径和耗时可以这样连续用多个sed表达式分号隔开做一轮清洗sed -E s/^([0-9-] [0-9:]).*user_id([0-9]).*path(\S).*cost([0-9])ms/\1 \2 \3 \4/这条命令的核心思路是用圆括号分组捕获需要保留的片段再用\1 \2 \3 \4重组成新的输出行。如果只想去掉行首的日期时间也可以简洁地用一个替换完成sed -E s/^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2} //。3.4 sed里的大坑贪婪匹配与转义层级sed最常见的问题是替换范围失控。原因是正则默认是贪婪的.*会尽可能匹配更多字符。比如你用sed s/title.*\/title//去删除HTML标题如果一行里出现两个title标签它会把第一个title到最后一个/title之间所有内容都删掉而不是只删第一对。解决思路有两个一是把.*改成[^]*这类更精确的字符类二是改用非贪婪模式PCRE才支持sed不原生支持所以在sed里我更推荐前者。另一个坑是命令行里的多层转义。特别是当你用sed替换的内容里同时含反斜杠、美元符号、引号时不光要照顾正则引擎的转义规则还要照顾Shell的解析规则。我的经验是优先用单引号包裹sed表达式避免Shell对$、*、\做额外解释如果内容里也有单引号可以用代替并小心处理或者把sed脚本写到文件里用-f加载代码可读性会好很多。4. awk面向列的文本处理主力awk是我这三件套里最后学会但使用频率最高的一个。它的设计核心是把每一行按分隔符拆成若干字段列然后基于这些字段做逻辑判断、统计计算和格式化输出。很多初学者只拿awk当打印第几列的工具这其实是把它的大材小用。awk本质上是一个完整的文本处理脚本语言有变量、有数组、有循环、有函数。4.1 awk的运行模型与内建变量awk处理文本时默认按行循环读取数据每一行会依次经过你的模式判断和动作块。基本语法是awk 模式{动作}模式可省略表示所有行动作可省略表示打印整行。awk有一套内建变量需要先记牢FS字段分隔符默认是空白空格或Tab可以自己指定比如FS,。OFS输出字段分隔符默认也是空格决定你print多个字段时用什么分隔。NR当前行号从1开始是全局计数器。NF当前行的字段数量通俗讲就是这一行被拆成了几列。$0整行内容。$1、$2第1列、第2列以此类推$NF表示最后一列。awk还有一种常用的结构是BEGIN和END块。BEGIN在读取任何数据之前执行适合设置分隔符、初始化变量、打印表头END在所有数据处理完之后执行适合输出统计结果。这种结构用来写报表特别顺手。4.2 实战案例一快速统计日志中的请求分布假设app.log每行记录一个请求格式是时间 客户端IP 请求路径 状态码。你想知道每个IP发起了多少次请求只需要一条awkawk {count[$2]} END {for (ip in count) print ip, count[ip]} app.log这里用了一个awk关联数组count键是第二列IP每次遇到同一IP就让对应的计数加一。处理完全部行之后在END块里遍历数组打印结果。如果还想按访问次数从大到小排序可以再接sortawk {count[$2]} END {for (ip in count) print count[ip], ip} app.log | sort -rn这个模式我在分析日志时反复使用比写Python脚本处理快很多因为awk本身就是为这种逐行扫描、累积统计设计的。4.3 实战案例二多条件组合过滤与计算awk还可以当带正则且能算数的grep。比如你想看状态码是500的请求中耗时超过1000毫秒的那些行并把它们的耗时换算成秒awk $5 500 $6 1000 {print $1, $2, $6/1000 s} access.log注意字段类型的问题awk里如果字段是纯数字字符串它会被自动当作数值参加比较运算这在日志分析中帮了大忙不用手动转型。但也因此有坑如果某个字段是123abc这类混合内容awk会尽量把它解析成123逻辑上可能跟预期不符。所以我做严格相等判断时会习惯给值加上双引号写成字符串比较比如$5 500。4.4 awk做多文件处理和嵌入正则awk支持同时读取多个文件而且你可以用FNR当前文件内行号和NR总行数来区分处理边界。比如把两个CSV文件按用户ID做简单关联合并就可以用awk实现虽然逻辑复杂一些但省掉了写Python关联脚本的功夫。另外awk的正则匹配可以用~运算符$0 ~ /^ERROR/表示当前行匹配以ERROR开头的模式才执行动作不匹配则跳过。4.5 awk里要注意的格式问题awk输出默认没有对齐打印多列时间隔只看OFS默认空格。如果你希望规则对齐可以用printf做格式化例如printf %-20s %s\n, $1, $2这个我在生成报表时用得非常多。另外awk里字符串拼接不需要运算符直接把要拼的内容挨着写就行比如print $1 - $2这个-就是字面量不需要加号。有些初学者会误用加号拼接字符串结果数字变成加法。5. 三剑客联动管道里的经典组合拳前面分别讲了grep、sed、awk各自的用法但实际工作中它们极少单独使用更多的是通过管道|组合成一个数据处理流水线。理解这个流水线模型比单独记每条命令的参数更重要。5.1 分工定位谁负责哪一段三件套在管道里的分工是这样grep负责筛选行sed负责对行内容做编辑awk负责按列重组和统计。用一句话概括grep决定走哪些行sed决定改成什么样awk决定怎么算怎么看。以分析nginx日志为例一个典型的组合是grep -E 2026-05-12 access.log | grep -v POST /api/health | awk {print $1, $9} | sort | uniq -c | sort -rn | head -20这条管道做的事情依次是筛出指定日期、排除健康检查请求、用awk提取IP和状态码、sort排序因为uniq统计前必须先排序、uniq -c统计次数、再按次数降序、最终只看前20条。即使不逐条解释你应该也能感受到这种写法的表达能力一条命令就是一个微型的ETL流程。5.2 学会用sort和uniq给awk做后处理awk的统计结果默认是无序的这在前面的IP统计案例里也提到过所以几乎总是要接sort。sort -n按数字排序、-r倒序、-k指定排序键列这些参数和awk配合很紧密。uniq -c则是去重并计数的利器但它有个前置条件输入必须是连续相同的行。所以sort在uniq前面几乎是标准的固定搭配。我在很多脚本里都见过sort | uniq -c的使用想不明白排序顺序导致统计出错的新手十有八九是漏了sort这一步。5.3 管道中sed的位置与作用sed在管道中的位置一般在grep之后、awk之前因为它的核心职责是清洗。比如日志里某些字段有特殊前缀或多余的引号先用sed做一次规范化awk后面按列处理时才会精确。有一个例子从Tomcat日志中提取某个线程ID和耗时数据日志里自带双引号和时间戳方括号导致awk按列拆分时列序号对不上。我在中间加一条sed -E s/^[0-9-] [0-9:.] //; s/[\[\]//g去除时间戳和引号awk再处理就清爽多了。管道的好处就是每一级职责单一、便于单独调试哪一步输出不对单独跑一遍那段命令就能看出来。5.4 命令组合时小心管道细节管道拆分的原始输出包含了文件名前缀比如grep -rn something /etc/的结果是/etc/xxx.conf:匹配行这样的格式如果你喂给awk按列处理列序号会跟你预期不一致。这时要么去掉-H或改用显式文件名要么用awk的:分隔符拆开处理。另一个常见坑是默认IFS内部字段分隔符对管道输入仍然生效awk默认只按空格和Tab拆列如果你的字段是用逗号分开的必须在awk里显式设置FS,否则$1会变成整行前半段带空格的垃圾。类似地如果分隔符是竖线还要注意竖线在正则里的特殊含义得写成FS\\|。6. 对新手最有价值的十几个坑和实战经验最后这部分我把自己实战中反复遇到、也是网上教程很少仔细讲的坑集中列一下。每一行背后都是实际出过问题的地方希望你在自己的脚本里能绕开。6.1 正则匹配结果的假阳性正则写宽松了容易匹配到不想要的内容比如你只想匹配index.html但模式写成了index.*html结果把index_catalog_html之类的也匹配出来了。我总结的方法是匹配越具体越好能用字符类限定的就尽量少用点号能锚定行首行尾的一定要锚定。写正则之前先想清楚什么样算匹配成功的确切边界。6.2 grep -v的退出码盲点grep -v匹配的是不匹配原始模式的行如果你的意图是排除某个内容之后还有没有其他内容要小心退出码的语义当所有行恰好都匹配原始模式时grep -v后什么都没有退出码是1。在脚本里if ! grep -v pattern file | grep -q other这种嵌套判断时很容易被这个语义绕晕。我的建议是复杂判断尽量拆成多个简单判断逐步执行每个步骤用echo打印中间结果验证。6.3 sed的-i选项在不同系统上的差异Linux的GNU sed允许sed -i s/foo/bar/ file直接改文件但macOS自带的BSD sed要求sed -i s/foo/bar/ file这个区别非常经典也是很坑的跨平台差异。如果你的脚本要在多种系统上运行建议要么统一用sed -i.bak形式同时生成备份文件要么在脚本开头用uname判断系统类型再决定用哪种写法。6.4 命令替换与文本处理结合时的引号陷阱在Shell脚本中经常用$(command)把命令输出赋值给变量比如date_str$(date %Y%m%d)这没问题。但如果你把包含正则特殊字符的文本放进了变量然后再把它塞进sed或grep的模式里就会出现变量中的*、.等字符被当作正则情况。解决方式是在需要字面匹配的场景下使用grep -F或对变量做转义处理。比如我要把用户传入的路径字符串作为文本搜出来用grep -F ${user_input}最保险。6.5 awk的数组遍历顺序不保证awk的关联数组在for (key in array)遍历时顺序是不确定的。如果需要固定顺序输出就先把结果交给sort或者用awk内部的下标排序方法。最省事的做法是awk只负责统计排序交给sort处理不要在awk里自己做太多排序逻辑避免语义复杂还容易出错。6.6 大量文件处理的性能认知很多人觉得Shell处理大数据量慢其实不一定。grep、sed、awk在底层的C实现里做过大量优化处理几GB级别的日志往往只需要几秒到几十秒。如果你的脚本处理到上GB文件时明显卡顿多数情况是管道设计有问题比如中间结果多次读写磁盘、循环里反复启动新进程等。正确的做法是尽量用单条管道完成全流程减少中间落盘和循环调用的次数。6.7 处理Windows来源文件时注意\r符号从Windows传过来的文本文件经常带有\r回车符在Linux里会被当作行尾的隐藏字符导致匹配时明明肉眼看着一样却匹配不上的尴尬场面。处理方式很简单先过一道sed -i s/\r$// file把\r清掉。做日志分析前我通常会在开头加这条避免后面每次都被莫名其妙的隐字符折磨。6.8 在脚本中如何安全使用grep -qgrep -q在脚本里做条件判断很常见但要注意它会把标准输入全部读完才返回车底判断的现象很常见。在管道中间用grep -q会导致前一个命令收到管道中断信号SIGPIPE有时候这个信号会让前一个命令报错甚至让整个管道提前终止。安全做法是确实需要判断管道数据里是否存在某模式时可以先把数据写入临时文件或使用tee缓存避免影响主流程。6.9 正则里的中文与多字节问题Locale设置会直接影响正则匹配多字节字符的行为。在UTF-8环境下[[:alnum:]]通常能正确匹配中文但\w在某些版本和语言环境下可能只匹配英文字母数字和下划线。我处理中文日志时一般不会依赖\w匹配中文而是用明确的字符范围或直接匹配具体的字符串片段虽然丑陋但稳定可靠。6.10 善用命令行的Debug技巧最后分享一个工作方式层面的经验写长管道命令时不要一次性把整条命令写完直接执行。正确的节奏是分段调试每加一个环节就打印一次中间结果确认这级输出没问题再接下一级。比如先跑grep -E pattern file | head看看行筛选得对不对再添上| sed -E ... | head检查清洗效果最后接awk做统计。这样排查问题时你能非常明确地知道是哪一环出了问题。如果你用的Shell支持还可以借助set -x让脚本边执行边打印每个命令的展开结果这个在一个复杂脚本里排错时太有用了。7. 综合案例一条命令完成多维度访问日志分析报告为了把前面讲的东西串成一个完整可运行的故事我这里给出一个综合案例。假设你有一个nginx格式的访问日志access.log字段顺序为客户端IP - 访问时间 请求方法 请求路径 协议 状态码 响应大小 响应耗时。现在我想知道哪些IP访问次数最多。哪些请求路径响应时间最长平均耗时。每日错误状态码5xx的分布。一条组合命令大致可以这样写# 每个IP的访问次数按次数降序 awk {print $1} access.log | sort | uniq -c | sort -rn | head -10 # 每个请求路径的平均响应时间按平均耗时降序 awk {path$(7); total[path]$(NF); count[path]; avg[path]total[path]/count[path]} END {for (p in avg) print avg[p], p} access.log | sort -rn | head -10 # 每日5xx错误数量分布 awk $9 ~ /^5[0-9][0-9]$/ {print $4} access.log | cut -d: -f1 | sort | uniq -c这三条命令都是awk统计 sort排序 head取前N条的结构但针对的维度和处理字段的逻辑不同。这里的$NF是指每行的最后一个字段也就是响应时间$9是状态码列$4是时间列里的日期部分。如果你想彻底模拟真实场景还可以把这三条命令加上循环分别计算每个小时段的趋势或者用sed先把不需要的路由清洗掉再统计。逻辑并不复杂关键在于你对每个字段的位置烂熟于心。我的做法是先打印一条样本行做列的验证再写处理命令最后把输出重定向到report.txt里。这类先观察样本、再设计模式、再组合管道的流程就是我日常处理文本的完整套路。你先拿几行样本数据手动验证正则能匹配、awk的列序号正确再放心地跑全量数据。命令一次跑对了效率比写个小脚本快好几倍。回到文初那个日志分析任务最后我用一条不到一百字符的管道命令把峰值响应时间上线的接口IP、请求路径、时间分布全摸清了全程没打开任何编辑器。那次的体会很深Shell文本处理能力不是靠记命令背出来的而是靠实际排坑、组合、调试中沉淀出来的。正则和文本处理器就像每个程序员工具箱里那把最常用的瑞士军刀初看平平无奇用顺了之后你会在任何时候都先想起它。希望这篇里写的那些坑和方法能帮你把这条路走得更直一点。