处理线上问题的时候我打开服务器的第一件事一般不是tail -f而是先用grep把日志里的关键字捞出来。linux grep命令这个工具表面上就是“在文件里搜个词”可真用熟了之后你会发现日志排障、代码检索、数据筛选、脚本监控全都离不开它。这篇东西不是 man 手册的翻译也不是培训课的目录而是我这么多年实际用下来沉淀出的那套“最常用的写法、最容易翻车的坑、以及真正节省时间的组合思路”。准备入门的读者可以把它当一份带注释的实战笔记已经会用基本参数的老手重点可以直接跳到后面的踩坑部分。很多人把 grep 理解成“CtrlF 的命令行版本”这个理解不算错但太窄了。搜索只是入口匹配规则的表达能力才是它的核心。同一个需求grep error和grep -E error|fatal搜索出来的结果是两个量级——前者等于是按关键词找行后者是“找一类日志”。这种从“字面搜索”到“模式匹配”的思维转变才是我觉得 grep 最值得投入时间去学的部分。1. 为什么 grep 值得花时间学透从一次日志排障说起1.1 一次深夜排障让我重新认识了 grep还记得某次线上服务半夜报警用户反馈接口响应特别慢我登录到服务器上第一个想法是“把日志找出来看看”。结果那个日志文件已经滚到了八百多兆less打开翻页翻到手指抽筋编辑器更是不可能。当时我下意识敲了一句grep -n SlowRequest /var/log/app/access.log | tail -n 50几秒钟之后最近五十条慢请求的记录全部列出来了而且带着行号。紧接着我又用两三个命令把慢请求的前后上下文、出现频率、来源 IP 都摸了一遍前后不到五分钟就锁定了问题方向。那次之后我就明白了一个道理在服务器上排查问题效率不是靠什么高端工具而是靠把最基础的命令用到极致。很多新手觉得 grep 太简单不值得专门学很多老手则只会grep xxx加一个-r。这两种状态都挺可惜。grep 的参数看起来多但真正高频的其实只有那么十几个把它们组合起来基本能覆盖日常 90% 的搜索场景。1.2 grep 解决的核心问题到底是什么往本质里说grep 做的事情只有一件从输入流或文件里按照某种模式筛选出符合条件的行并输出。它不负责修改文件不负责统计计算不负责排序去重——这些是 sed、awk、sort、uniq 的事。很多人用不好 grep就是因为总想让一个命令干完所有事结果写出一长串又长又绕的管道。我经常用一个比喻把 grep 当成一个安检口它只负责“放行哪些人”不负责登记、拍照、测体重。安检规则由正则表达式定义放行结果输出到屏幕上或者传给下一个命令。理解了这个定位你就能想明白为什么 grep 的退出码是那样的——0表示找到了匹配行1表示没找到2表示出错了。这个设计是为了方便脚本做判断后面我会专门讲。1.3 该投入多少精力学 grep 才算值以我的经验投入产出比最高的学习路径是这样的先把-E、-v、-n、-c、-l、-o、-A、-B、-C、-r、--include这几个参数练熟再掌握正则里的字符类、量词、锚点、分组这四类语法就已经能处理绝大多数工作了。至于什么前瞻断言、后向引用属于“用到再查”的范畴不影响日常。换句话说grep 的 80% 价值来自 20% 的功能。但如果你想从事运维、后端或者数据分析相关的工作那剩下那 20% 的功能——主要是正则的高级写法和与 xargs、find 的配合——反而决定了你能不能把“看起来要写程序才能解决的事”用一条命令解决掉。这也是为什么我建议每个用 Linux 工作的人都值得把 grep 从“会用”提升到“用得讲究”。2. 正则表达式是 grep 的灵魂先转变匹配思维再记参数2.1 从字面匹配到模式匹配grep error app.log这种写法本质上是在每一行里找一个固定的子串只要这行里包含error四个字母就会输出。但真实场景里很少有这么多死板的搜索需求。举个我经常遇到的例子日志里错误类型是error_code_1001、error_code_1002……一直到error_code_1010。用字面搜索你得搜十次用模式搜索一次就够了grep -E error_code_100[1-9]|error_code_1010 app.log这里[1-9]是一种“字符类”表示匹配 1 到 9 中的任意一个数字|表示“或”-E表示开启扩展正则。正则表达式的本质就是用一套符号去描述“一类文本”而不是一个一个地列出所有可能。一旦接受了这个思路你的 grep 就不再是“高级搜索框”而是一种轻量级的文本处理语言。2.2 基本正则和扩展正则到底选哪个很多教程会先讲 BRE基本正则再讲 ERE扩展正则然后告诉你“grep 默认使用 BRE”。这句话本身没错但它害不少人踩了坑。因为在 BRE 模式下(、)、{、}、|、、?这些字符如果不加反斜杠就只是普通字符不会产生特殊含义。也就是说grep error|fatal file搜的其实是字面意义上的“error|fatal”这串字符而不是“error 或 fatal”。我个人的建议非常明确日常使用统一加-E也就是扩展正则模式。原因很简单ERE 的语法更接近现代正则的通用写法可读性好也不需要纠结哪些符号该转义。比如分组和量词在 ERE 下直接写(ab)、[0-9]{3}而 BRE 下必须写成\(ab\)\、[0-9]\{3\}视觉噪音太大还容易写错。有一种例外是grep -P它启用 PCREPerl 兼容正则支持前瞻断言、后向引用等高级语法。比如想匹配一个 IP 地址并且确保后面不跟数字用-P的(?!\d)会更方便。但-P在不同系统上的表现不完全一致性能也不一定好所以我只在需要它的高级特性时才用日常还是-E为主。2.3 常用正则语法配上日志场景拆解不空谈语法直接看几个我在日志分析里反复用的例子。第一个匹配当天某个时间段的记录grep -E ^2024-05-01 14:[0-9]{2}: app.log^是行首锚点表示这一行必须以后面的内容开头[0-9]{2}匹配两位数字。日志如果按标准格式每行起始是时间戳这个写法就能把当天 14 点的请求全部拿出来。这里有个细节14:[0-9]{2}:里的冒号不需要转义但[、]、{、}、|在 ERE 下都是有特殊含义的符号搜索纯文本时要注意。第二个匹配超时时间并提取具体数值grep -oE timeout after [0-9]ms app.log-o表示只输出匹配到的部分而不是整行。配合sort和uniq -c可以把“超时 800ms 出现了多少次”统计出来这在调优时非常有用。表示前面的字符出现一次或多次对应“至少一位数字”。第三个搜索特定 IP 段grep -E 10\.0\.1\.[0-9]{1,3} app.log这里点号.在正则里匹配任意字符所以如果要匹配真实的点号必须写成\.。新手最容易忽略的就是这个导致搜索192.168.1.1时把192x168y1z1这种乱七八糟的也搜出来。记住一句话在正则里你想匹配哪个普通字符就要反过头来想想它是不是特殊字符是的话就转义。3. 日志排障实战几个高频场景的 grep 组合打法3.1 只看错误行往往不够加行号和上下文日志排障和普通搜索最大的区别是你需要的不是“哪一行出错了”而是“出错前发生了什么、出错后影响到了什么”。grep -n可以带行号grep -B显示匹配行之前的若干行grep -A显示匹配行之后的若干行。我处理崩溃类错误的时候几乎固定会这样写grep -n -B 3 -A 10 OutOfMemoryError /var/log/app/app.log-B 3的意思是看异常出现前 3 条日志通常能抓住导致内存涨高的最后几个操作-A 10的意思是看异常出现后 10 条日志判断进程是继续跑还是直接挂了。如果你不确定前后该看几行可以直接用-C 5它等价于-B 5 -A 5两边各取 5 行。这个组合最大的好处是少敲命令。以前我习惯先 grep 出行号再用sed -n 1200,1220p去截取片段现在一步就完成了。而且因为输出里带着行号后续要定位代码文件时也很方便。3.2 日志量太大时先用 grep 裁剪再用 awk 精算日志文件动辄几百兆直接全量分析很痛苦更聪明的做法是先按时间段做粗筛再对筛选结果做细算。比如想看 5 月 1 日下午 2 点到下午 4 点之间的错误日志grep -E ^2024-05-01 1[4-6]: app.log | grep -E ERROR|FATAL正则1[4-6]能匹配 14、15、16 三个小时的数字。这里有个小坑如果想匹配 14 点到 16 点写成14|15|16在正则里按“或”处理是没有问题的但一旦你写到1[4-6]这种范围时需要想清楚它是“小时十位是 1个位是 4 到 6”而不是“从 14 到 16 的所有数字”。对于简单的范围正则够用一旦涉及跨天、跨小时的精确时段计算我一般会换成 awk它的数值比较更直观awk -F[: ] /^2024-05-01/ $2 14 $2 16 app.loggrep 负责粗筛、awk 负责精算两者搭配比硬着一个工具高效得多。3.3 统计错误出现次数和分布grep sort uniq想知道某类错误一共出现了多少次最简单的是grep -c ERROR app.log-c会直接输出匹配行数。但更常见的情况是想看错误的时段分布比如“这半天里每个小时的错误数是多少”。我一般这样写grep ERROR app.log | grep -oE ^2024-05-01 [0-9]{2} | sort | uniq -c这段命令的每一步都值得拆开理解第一步把 ERROR 行全筛出来第二步用-o只提取每行开头的时间到小时级别第三步sort排序让相同时间聚在一起第四步uniq -c统计每项的重复次数。最终输出会像这样134 2024-05-01 14 289 2024-05-01 15 521 2024-05-01 16这种流水线式的命令组合是命令行分析数据的基本功。你不需要写 Python 脚本一条命令就能得到粗糙的分布规律再决定要不要深入排查具体某个时段。3.4 过滤噪音用 -v 把不关心的行剔除日志里经常有大量健康检查请求它们本身可能包含ERROR字样但根本不是真正的业务异常。这时候用反向匹配-v最方便grep -E ERROR|FATAL app.log | grep -v healthcheck第二个grep -v的意思是“排除包含 healthcheck 的行”。同理查看配置文件时可以排除注释和空行grep -vE ^#|^$ /etc/nginx/nginx.conf^#匹配以 # 开头的注释行^$匹配空行-E让|生效。只打印实际生效的配置项这种用法在排查配置文件问题时非常实用。注意-v和-E可以组合成-vE也可以分开写成grep -v -E效果一样。4. 参数组合与高频用法我命令行里沉淀下来的命令写法4.1 项目代码检索-r 与 --include/--exclude 配合在代码库里搜东西是 grep 的另一大高频场景。比如想知道项目里哪些地方调用了一个函数或者哪些配置里写了某个环境变量直接对整个源码目录递归搜索grep -rn api_token src/ config/-r表示递归搜索目录下所有文件-n表示显示行号。不加-n的话结果里只有文件名和匹配内容定位到具体行还得再翻一遍所以建议默认带上。项目仓库里往往混着各种文件为了不搜出一堆node_modules、构建产物和二进制文件我通常会加--include指定只搜某些类型grep -rn --include*.py --include*.js api_token src/反过来也可以用--exclude排除某些文件用--exclude-dir排除某些目录grep -rn --exclude-dir.git --exclude-dirnode_modules api_token .这里还有一个细节-r和-R的区别在于-R会递归跟随符号链接-r不会。如果项目里有用软链接指向的目录而你确实想搜进去就改用-R。大多数项目里符号链接很少所以默认用-r更安全避免陷入循环链接。4.2 只看文件名或计数-l、-L、-c 在批量操作中的价值有时候你根本不关心匹配内容是什么只想知道“哪些文件里有这个东西”。这种场景用-l最合适它只打印文件路径不打印匹配行grep -rl EndpointV2 src/输出会是一列文件路径。配合 xargs 可以立刻对这些文件做批量操作比如批量替换、批量删除。反过来想知道哪些文件里不含某个模式用-Lgrep -rL Copyright src/这在做合规检查时非常有用——比如检查哪些源码文件遗漏了版权声明。-c则直接给每个文件的匹配计数适合快速对多个文件做横向对比grep -rc ERROR logs/注意grep -c file在文件内匹配数为 0 时输出0但退出码是 1这在写脚本时是个容易踩的坑后面专门讲。4.3 高频参数速查表参数作用典型使用场景-E使用扩展正则用 -i忽略大小写搜索不区分 ERROR/error-v反向匹配排除噪音行、过滤注释-n显示行号定位代码或日志位置-c只输出匹配行数量快速计数-l只输出包含匹配的文件名批量判断哪些文件命中-L只输出不含匹配的文件名检查遗漏项-o只输出匹配部分提取 IP、时间、数值-w按单词边界匹配避免 error 匹配到 error_code-x整行精确匹配精确过滤某一行内容-F纯字面字符串匹配搜索文本中的特殊字符不做正则解释-q静默模式不输出任何内容脚本条件判断-A N显示匹配行后 N 行查看异常后续影响-B N显示匹配行前 N 行查看异常前置原因-C N显示匹配行前后各 N 行查看上下文-r递归搜索目录代码仓库检索--include只搜索指定模式文件限定文件类型--exclude排除指定模式文件跳过构建产物--exclude-dir排除指定目录跳过依赖目录--colorauto匹配内容高亮提高肉眼识别效率这张表不需要背真正用的时候回来查就行。核心是知道 grep 有这么多“输出形态”可以选择不同场景挑不同的参数组合而不是永远只写grep 单词 文件。5. 踩坑实录grep 用错的五个瞬间5.1 忘了转义或忘了加 -E正则没生效最经典的坑是正则里的花括号和竖线“神秘失效”。比如我想搜连续三个数字心里想的是[0-9]{3}但写出来却是grep [0-9]{3} app.log由于默认是 BRE 模式{和}在这里是普通字符这个命令实际搜的是“一个数字、然后一个左花括号、然后数字 3、然后右花括号”基本什么都搜不到。正确写法是grep -E [0-9]{3}或者老老实实转义grep [0-9]\{3\}。我后来给自己定了一条规矩只要正则里出现了{、}、、?、|、(、)中的任何一个就毫不犹豫地加-E绝不在 BRE 下靠转义续命。这样既减少了错误也让命令更容易被同事读懂。5.2 管道符号被 shell 抢走命令直接跑飞想在一条命令里匹配“error 或 fatal”新手很容易直接写grep error|fatal app.log这个写法有两个潜在问题。第一在 BRE 模式下|是普通字符命令会搜索包含字面文本error|fatal的行结果自然是空的第二如果你不加双引号写成grep error|fatal app.logshell 会先把|解释成管道把grep error的输出交给fatal app.log这个命令去执行结局可能是“找不到 fatal 命令”甚至更严重的误操作。正确做法是要么加引号并加-E让正则生效要么用多个-e参数grep -E error|fatal app.log grep -e error -e fatal app.log在 shell 里写 grep凡是用到空格、|、、*、$等特殊字符的时候都要养成交叉检查“这到底会不会被 shell 先解释掉”的习惯。最安全的办法就是把匹配模式当成一个整体用双引号包起来。5.3 Windows 换行符让行尾匹配失效有一次我从同事那边拿到一个日志文件用grep -E ERROR$搜了半天一条结果都没有。单独搜ERROR又能搜到。这就很让人摸不着头脑。后来用file命令检查了一下发现文件是 CRLF 换行也就是每一行的结尾其实是\r\n而不只是\n。问题出在这里$表示“行尾”但在 CRLF 文件里ERROR后面还跟着一个不见的\r字符所以ERROR$永远匹配不上。解决办法很简单先转换换行符再 grepsed -i s/\r$// app.log grep -E ERROR$ app.log如果不想改文件本身也可以用tr -d \r去掉所有回车符号后通过管道传给 greptr -d \r app.log | grep -E ERROR$从那以后我拿到来源不明的文本文件第一件事就是file看一眼格式。这个习惯帮我避免了不少“明明应该匹配却搜不到”的诡异问题。5.4 遇到 “Binary file matches”加了 -a 才看清内容搜索日志时偶尔会碰到输出只有一行Binary file matches而不是具体的匹配行。这是因为文件里有非文本字节grep 检测到二进制特征后就自动切换了行为只告诉你“匹配到了”不打印具体内容。真实场景里日志文件可能因为写入异常夹杂了乱码或者某个字段带了不可见控制字符。这时候加-a强制按文本处理grep -a -E ERROR app.log-a等价于--binary-filestext意思是“别管二进制不二进制按文本处理”。还有一个相关的坑如果文件的编码不是 UTF-8比如是 GBK在 UTF-8 的终端环境下搜中文关键词也可能出现搜不到或者乱码。我的处理办法是用file确认编码必要时先转码file app.log iconv -f GBK -t UTF-8 app.log app_utf8.log grep 中文关键词 app_utf8.log5.5 大文件搜索慢-F 和 LC_ALLC 能明显提速有一次在一个十几 GB 的日志文件里搜一个纯字符串关键词命令跑了几分钟还没出结果。原因是我用了正则模式哪怕正则里没有任何特殊字符grep 依然要按正则引擎去处理每一行。对于这种场景更快的方案是让 grep 知道“我搜的是纯文本”用-F固定字符串匹配grep -F RequestTimeout big.log-F会跳过正则解析匹配速度快不少。如果还想再快一点可以临时把 locale 设置为C。grep 在多字节 locale 下会做更复杂的字符处理而LC_ALLC让它在单字节模式下处理文本对纯 ASCII 内容的日志提升明显LC_ALLC grep -F RequestTimeout big.log在写管道和脚本时也可以用--colornever减少输出转义码虽然对速度影响不大但能让重定向到文件的结果干净很多。6. 从手工到脚本把 grep 变成监测和巡检工具6.1 用退出码做条件判断取代肉眼盯屏grep 的价值不仅在于交互式搜索还在于它能变成一个自动化判断工具。前面提到grep 的退出码是0有匹配、1无匹配、2出错。这意味着在 shell 脚本里可以直接用 grep 的结果作为 if 条件不需要再写复杂的字符串比较。比如一个简单的日志巡检脚本#!/bin/bash LOG/var/log/app/app.log if grep -q OutOfMemoryError $LOG; then echo [告警] 检测到内存溢出日志 grep -n OutOfMemoryError $LOG | tail -n 5 else echo [OK] 未检测到内存溢出 fi这里用-q的关键在于我只需要判断有没有匹配不需要它输出内容。如果不加-qgrep 会把所有匹配行都打到屏幕上如果匹配几千行脚本输出就爆炸了。另外-q在找到第一个匹配后就会停止读取文件对超大日志的巡检也更省资源。有一个容易忽略的细节grep -c的退出码跟“有没有匹配”绑定而不是跟“计数结果是否为 0”绑定。也就是说grep -c ERROR file如果文件里一个匹配都没有它会输出0但退出码是1。如果在set -e的严格模式下直接使用脚本可能意外退出。稳妥的写法是count$(grep -c ERROR $LOG || true)|| true的作用是把退出码强行置为 0既不影响取到计数也不会让脚本中断。这个细节我踩过不止一次写在这里提醒大家。6.2 配合 find 和 xargs批量扫描多个文件grep -r能递归扫目录但有些场景需要更精细的控制比如“只扫最近三天修改过的日志文件”或者“文件名符合某个规则才处理”。这种时候find xargs grep的组合更灵活find logs/ -name *.log -mtime -3 -print0 | xargs -0 grep -c ERRORfind负责筛选文件列表-mtime -3表示最近三天内修改过的文件-print0用空字符分隔文件名是为了防止文件名里有空格导致参数断裂xargs -0必须和-print0配套使用两边都得加。然后把文件名列表交给 grep-c逐文件统计错误数最后的输出是“文件名: 计数”的形式。如果只想看哪些文件有错误可以换成grep -l后面再接xargs做进一步处理比如把出错次数较多的文件打包发到分析目录。这套组合的威力在于它把文件筛选和内容筛选串联起来比单独grep -r更能应对复杂条件。6.3 一个简单的巡检函数日常可以直接用为了方便我经常在 shell 配置里放一个很简单的函数用来快速判断某个模式在文件里出现的位置和数量check_log() { local file$1 local pattern$2 echo 文件: $file 模式: $pattern grep -n $pattern $file | tail -n 10 }使用的时候check_log /var/log/app/app.log Timeout几秒钟内就能看出最近命中位置。如果文件特别大也可以替换成grep -n $pattern $file | head -n 10先看前面的部分。这种函数没什么技术含量但它体现了 grep 使用的一个核心思路别每次重复敲一长串命令把常用的分析动作沉淀成语义清晰的工具时间久了积累出来的效率非常可观。最后一个使用习惯也是我想借这篇文章分享的最重要一点写 grep 命令时给匹配模式加引号这个动作应该形成肌肉记忆。不管模式里有没有特殊字符我都习惯用双引号把它包起来因为没有人能保证下一次搜的内容里不会出现空格、$、*或者中文标点。被 shell 展开毁掉的命令远比我需要在这里列举的多。grep 的语法本身并不难难的是在各种环境里稳定地输出你真正想要的结果而这些细节恰恰是决定一个命令“好用”还是“不好用”的分水岭。