1. grep 的脾气一台只认行不通融的文本筛子很多人第一次学 Linux 命令都是从grep开始的理由也很简单——查找字符串这件事听起来没有门槛。但真正在生产环境里用上三个月你就会发现grep相关的故障单能占到命令类问题的一大半明明文件里写着这个字符串就是搜不出来明明只想看日志里的一行结果刷屏几千行明明写进了脚本退出码却死活不对。问题不在于命令难而在于绝大多数教程把grep讲成了搜索工具而没有讲清楚它真正的行为模型grep是一个逐行做判定的筛子它的输入是行输出也是行中间的判定逻辑是一段正则。这三句话决定了它的全部使用方式。因为它按行处理所以它天然不擅长跨行匹配因为它的判定标准是正则而不是字面量所以关键词里的.、*、[、$都有特殊含义因为它的输出单位是行所以你想要匹配次数而不是匹配行数时必须额外加参数。把这些前提吃透后面那些看起来零散的选项就有了统一的解释-o是为了把行拆回匹配片段-A/-B/-C是为了把行扩展成上下文块-c是为了把行压缩成数量-l是为了把行降级成文件名。它们全都是在同一个行为模型上做的变形。这篇文章不谈命令手册式的罗列。我想按照真实排查路径来组织一个做后端运维或者写脚本的人从敲下第一条grep开始会遇到哪些判断点、哪些坑、哪些必须记住的取舍。如果你刚接触 Linux可以把它当作一份带解释的速查如果你已经用了几年可以直接跳到第 4 节往后那部分是我自己在线上环境里踩出来的经验。1.1 一次调用里grep 实际做了三件事抛开所有选项grep的执行过程可以拆成三步。第一步是取样从文件、标准输入或者递归目录里拿到一批行每一行的边界默认是换行符\n如果你加了-z边界就变成\0——这个选项在处理包含换行的文件名时特别有用。第二步是判定把每一行的内容注意默认不包含行尾的换行符喂给模式去做匹配匹配上了就标记为命中。第三步是输出命中的行被原样打印到标准输出如果加了-n就带行号加了--colorauto就把命中片段染色。这里有一个容易被忽略的细节判定时被匹配的字符串不含行尾换行符但它包含行尾的\r。这就是为什么从 Windows 拖过来的文件里grep foo$会失败而grep foo却成功——$锚定的是行尾而那一行的真实内容是foo\r$落在了\r后面。这个坑我在第 6 节会单独展开因为它造成的排查时间往往远超问题本身的复杂度。另外值得说明的是-r递归。很多人以为grep -r是把目录里所有文件拼成一个大流再搜索实际上它是逐个文件打开、逐行处理、边处理边输出。这个差别决定了你可以用grep -r ... | head提前结束而不必等它扫完全部文件也决定了-m这个限制参数是按文件生效的不是全局生效。理解执行顺序很多为什么它跑得这么慢的疑问会自己消解。1.2 退出码 0、1、2 才是脚本里最有价值的部分命令行里我们关心输出脚本里我们关心退出码。grep的退出码有三个值含义非常明确退出码含义常见误判0至少命中一行无1一行都没命中被当成出错处理2发生了错误文件不存在、权限不足、正则语法错被当成没匹配到处理新手写脚本最常见的错误就是把 1 和 2 混为一谈。比如grep -q $pattern $file || echo not found当$file根本不存在时grep返回 2脚本照样打印 not found于是你把文件路径写错了误判为里面没有这个关键字方向直接跑偏。正确的写法是把非零都当异常拦下来if grep -q -- $pattern $file; then echo found else rc$? if [ $rc -eq 1 ]; then echo not found else echo grep error, rc$rc 2 exit 2 fi fi还有一点加了-q之后grep会在第一次命中时立刻返回不再继续读文件。这在处理几十 GB 的日志时是实打实的性能优化我见过有人用grep -c去判断有没有白白扫完整个文件而grep -q可能一毫秒就返回了。1.3 查找字符串这个说法从一开始就带着误导grep的第二个参数是模式不是字符串。手册里的说法是 PATTERN而在默认模式下它被解释为基本正则表达式BRE。这意味着下面这些字符都不是它自己. * [ ] ^ $ \( \) \{ \} \举个我亲眼见过的例子有人想在一堆日志里找某个 IP 段写了grep 192.168.1.1 access.log结果把192x168y1z1、192-168-1-1这类内容全捞了出来。原因是.匹配任意单个字符。要按字面量匹配正确做法是grep -F 192.168.1.1 access.log或者逐字符转义grep 192\.168\.1\.1。所以每次有人跟我说grep 搜不到我的第一反应永远是两个问题你要找的是字面量还是模式如果是字面量为什么不用-F把这两个问题问清楚能省掉一大半的无效排查。2. 正则方言的选择BRE、ERE、PCRE 到底该用哪个grep支持多种正则方言切换方式是命令行开关。这个设计是历史包袱的产物但它带来的实际影响是同一段模式在不同开关下含义完全不同甚至完全不工作。搞清楚三者的边界比背下所有元字符更重要。2.1 基础正则里那些反人类的转义规则默认模式BRE的规则是普通字符就是普通字符元字符需要转义成特殊含义但有一小撮字符天生特殊。听起来绕列出来就清楚了字符BRE 中的含义ERE 中的含义.*[]^$元字符特殊含义同左\一个或多个需转义直接表示一个或多个\?零个或一个需转义?直接表示零个或一个|或者需转义\(\)分组需转义()直接分组\{n,m\}重复次数需转义{n,m}直接使用这个表的实用价值在于你从别处复制来的模式很可能来自 ERE 语境直接丢给默认grep会静默失配。比如grep error|warn app.log在 BRE 下|是普通字符它会去找字面上的 error|warn 这个字符串结果自然是一条都没有。这种失配不报错、不警告就是安静地返回空非常折磨人。我个人的习惯是只要模式里出现了|、、?、(、)、{、}中的任何一个就无条件加-E。与其在脑子里跑一遍转义规则不如让模式写法和脑中的预期保持一致。2.2 -E 与 -F 的取舍什么时候该放弃正则-E打开扩展正则-F则彻底关掉正则把整个模式当字面量。这两个开关不是高级和低级的区别而是两种完全不同的策略。判断标准很直白如果用户给你的搜索词来自输入框、配置文件、另一个程序的输出那就用-F。因为此时你无法保证这个词里没有元字符任何一次意外匹配都可能演变成数据泄露或者误删。给用户搜索框写后端实现的时候grep -F是默认选择而不是备选。反过来需要模式化匹配的场景必须上-E日志里抓所有 4xx 状态码grep -E (4[0-9]{2}) access.log或者一次抓多种级别grep -E ERROR|FATAL|CRITICAL app.log。除了模式本身-F还更快。它内部走的是字符串匹配算法不用编译正则、不用回溯在超长行或者海量小文件场景下的差距肉眼可见。我曾经在一个 8 GB 的文本上做过对比同一组关键词-F比默认的 BRE 快了接近三倍比-E还要再快一点。所以我确定是字面量的时候别嫌麻烦加上-F。2.3 -P 能救命但别把它当默认-P打开 PCRE 模式立刻解锁\d、\s、\w、\b、后向引用、前后查找这些在其它语言里用惯了的写法。写复杂模式时确实爽# 抓形如 2024-05-01T09:12:33 的时间戳 grep -Po \d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}但有两个现实约束必须知道。第一-P依赖编译时链接的 PCRE 库在一些精简发行版、容器基础镜像或者嵌入式环境里是没有的脚本一跑就报grep: support for the -P option is not compiled into this --disable-perl-regexp binary。如果你的脚本要在别人的机器上跑把-P当默认就是给自己埋雷。第二PCRE 支持回溯写不好会触发灾难性回溯在长行上直接卡死。所以我的原则是交互式排查可以用-P图省事写进脚本一律回到-E。顺便说一个高频需求——只输出匹配到的那一段而不是整行这靠-o配合-E也能做不是-P的专利grep -Eo [0-9]{1,3}(\.[0-9]{1,3}){3} access.log3. 引号、变量和短横线语法层面最容易翻车的三处模式写对了命令还是可能错。因为grep拿到的模式并不是你眼睛看到的那串字符而是shell 处理过一轮之后的字符串。中间这一层处理制造了大量看起来一模一样但结果不同的问题。3.1 单引号与双引号决定了谁先动手规则不复杂单引号里的内容 shell 原样传递双引号里的内容 shell 会先做变量替换、命令替换和部分转义处理。放到grep场景里这条规则决定了两件事。第一模式里含$时必须用单引号。$既是 shell 的变量前缀又是正则的行尾锚点。想匹配以 DB 开头的行写grep ^DB config.ini没问题但如果你想匹配字面量里的美元符号比如grep $100 price.txtshell 会试图展开变量$1和字符串 00$1为空模式就变成了 00结果自然是错的。正确写法是grep \$100 price.txt或者grep -F $100 price.txt。第二变量作为模式时引号的选择会改变语义。假设pa bgrep $p file # 等价于 grep a b fileb 被当成文件名 grep $p file # 正确整个 a b 作为一个模式不加引号时shell 会做词分割一个模式被拆成两个参数grep就会把b理解成第二个文件输出No such file or directory。这是脚本里出现频率最高的隐蔽 bug 之一。变量作为模式或文件名时永远加双引号这条规则没有例外。3.2 以短横线开头的模式必须用 -- 隔断如果搜索词恰好以-开头grep会把它当成选项解析报invalid option。比如你要在日志里找-ERR开头的记录grep -- -ERR app.log--是 POSIX 约定的选项结束标记它后面的所有参数一律按位置参数处理。这个技巧不只对grep有效rm、cat、ls都通用。在自动化脚本里我建议只要是外部传入的搜索词一律加上--成本是一个字符收益是杜绝了一整类注入式误解析。3.3 命令替换与 xargs 里的空格陷阱把grep的输出交给下一个命令处理时空格和换行会变成杀手。经典场景是找出包含某关键词的文件然后删掉# 危险文件名里有空格就会被拆开 rm $(grep -rl debugtrue ./conf) # 安全用 NUL 分隔传递 grep -rlZ debugtrue ./conf | xargs -0 rm --grep -Z让输出以\0结尾xargs -0按\0切分参数整条链路对空格、换行、引号都免疫。再配上xargs -r无输入时不执行命令GNU 扩展和--这套组合在批量操作里我用了很多年没出过事。4. 日志与进程排查真实场景里的组合拳前面三节是语法基础从这一节开始进入我每天真正在用的操作。4.1 追查日志上下文、行号与时间窗拿到一份应用日志第一件事不是直接grep ERROR而是先确认三件事文件多大、有没有被切割、编码是什么。跳过这三步很容易在错的文件上浪费时间。确认之后我通常这样起步grep -n -C 3 ERROR app.log-n给行号方便后续用sed -n 1200,1260p app.log精确回看-C 3同时输出上下各三行。这三个上下文行往往比 ERROR 本身更有价值异常堆栈的起因通常就在前两行。更常见的情况是日志量极大直接全量搜索会刷屏。这时候要按时间窗收窄。假设日志行首是2024-05-01 09:xx:xx格式grep -E ^2024-05-01 09:(1[0-5]|[0-5][0-9]) app.log | grep -E ERROR|Exception第一条grep把范围压到 09:10 到 09:15 这五分钟第二条再筛级别。把时间收窄和内容筛选拆成两条管道命令比写一条巨复杂的正则更好维护出问题时也更容易定位是哪一步出了偏差。还有一个技巧值得单独说用-m提前退出。如果你只想确认某个错误有没有出现过grep -m 1 OutOfMemoryError app.log在第一次命中后就停止读取。对一个 20 GB 的日志这可能把耗时从分钟级压到毫秒级。4.2 ps -ef | grep 总是多出一行这不是玄学ps -ef | grep tomcat的输出里总是多出一条grep tomcat这件事几乎每个 Linux 使用者都被困惑过。原因并不神秘管道两端的两个进程几乎同时启动grep自己的命令行里就包含 tomcat 这个字符串而ps恰好把grep进程也列了出来于是grep匹配到了自己。三种解法各有适用场合写法原理适用场景ps -ef | grep tomcat | grep -v grep再筛掉含 grep 的行最直观但链条变长pgrep -a tomcat直接按进程名匹配不经过自身推荐输出更干净ps -ef | grep [t]omcat模式是[t]omcat自身命令行里是字面[t]omcat不匹配只允许用 grep 时的经典技巧第三种写法的原理值得体会一下正则[t]omcat匹配的是 tomcat但grep进程自己的命令行参数是字符串[t]omcat其中包含了方括号所以匹配不上。这个用正则绕过自身的技巧在很多场景下都能用比如查找包含某关键词的脚本进程。另外提醒一句pgrep匹配的是进程名默认取/proc/PID/comm长度截断到 15 字符而ps -ef | grep匹配的是完整命令行。如果你的目标是一个 Java 进程进程名可能是java真正的标识在启动参数里这时候pgrep -af myapp.jar才是正解。4.3 在代码库里定位与替换前的确认流程想改一批代码先确认改哪些文件再确认改哪些行最后才动手。跳过中间任何一步都可能造成大面积误改。标准流程是两段式# 第一步只列文件名快速评估影响面 grep -rl --include*.java getUserName() ./src # 第二步带上行号和上下文逐个确认 grep -rn --include*.java getUserName() ./src先-l再-n的原因很实际-l的输出量小你能在几秒内判断影响 3 个文件还是影响 300 个文件。如果是后者说明模式写得太宽需要收窄比如加上-w做全词匹配或者用更长的上下文来限定。-w这个选项经常被忽略但它能挡掉一整类误伤。grep -w id不会匹配userId、id_card、grid只匹配独立的id。在重构变量名时它几乎是必备的。5. 递归搜索的边界控制别让 grep 把整个磁盘读一遍grep -r是效率杀手也是效率神器区别全在边界控制上。在项目根目录裸跑grep -r config .你会看到它一头扎进.git的对象目录、node_modules的几万个包、各种二进制产物输出里夹杂着Binary file ... matches的噪音跑几分钟都不结束。5.1 --include / --exclude-dir 的匹配规则控制边界主要靠四个选项grep -rn \ --include*.py \ --exclude*.min.js \ --exclude-dir.git \ --exclude-dirnode_modules \ --exclude-dirvenv \ DATABASE_URL .它们的行为有两处细节值得记住。第一--include和--exclude是按文件名匹配的支持*、?、[]这些 glob 通配符但不支持**这种递归通配。所以--include*.py有效--includesrc/**/*.py无效。需要按路径限定得换个思路。第二这几个选项只对递归搜索生效。如果你在命令行里显式列出文件名grep --include*.py foo a.txt依然会搜a.txt。这一点跟很多人的直觉相反我在好几个同事那里都见过这个误解。第三--exclude-dir默认匹配目录的 basename所以写.git能生效写./.git反而可能漏掉。从 GNU grep 2.5.3 开始如果模式里包含/它才会按完整路径匹配。这个细节在写通用脚本时要注意因为不同发行版打包的 grep 版本差异不小。5.2 -r 与 -R、符号链接与挂载点-r和-R的区别只有一条-R会跟随符号链接-r不会。默认情况下GNU grep 的-r遇到指向目录的符号链接会跳过。这个差别在某些目录结构下是致命的。比如部署目录里用软链把/data/app/current指向/data/app/releases/20240501如果你用-r在/data/app/current上搜索会正常进入因为起点本身是软链但子目录里的软链会被跳过。遇到搜索结果莫名其妙变少的情况先把-r换成-R试一次。但-R也有风险如果目录里存在循环软链A 指向 BB 又指回 A-R会陷入无限递归。GNU grep 加了一个-D选项来控制对设备、FIFO、套接字的处理但在循环软链上并没有自动保护。所以我的习惯是用-R之前先find . -type l看一圈有没有环或者在容器这种可控环境里才放心用。5.3 大文件与海量小文件的提速手段同样的搜索写法不同耗时可差几十倍。几个实测有效的加速手段# 关掉本地化字符处理走单字节快速路径 LC_ALLC grep -F needle bigfile.log # 只判断有无命中即退出 grep -q needle bigfile.log # 只统计数量但不输出内容 grep -c needle bigfile.log # 大目录并行搜索 find ./logs -name *.log -print0 | xargs -0 -P 8 -n 20 grep -l needleLC_ALLC的效果最容易被低估。在 UTF-8 locale 下grep 需要把每个字节序列解码成字符来处理大小写折叠和字符类而Clocale 下它可以按单字节直接比较。在 10 GB 级别的纯 ASCII 日志上我测到的差距在两到三倍之间。代价是中文等多字节字符的处理会变成按字节比较所以只对确定是 ASCII 的文件使用。并行那条命令里-P 8表示同时跑 8 个进程-n 20表示每个进程一次处理 20 个文件。这两个数字需要根据机器的核数和磁盘类型调。在机械硬盘上并行度太高反而会因为随机寻道导致整体变慢-P 2可能比-P 8更快在 SSD 上可以放心开到核数。6. 编码与换行匹配不到结果时的第一嫌疑模式写对、路径写对、权限也有结果还是空。这时候按我的经验顺序先查换行再查编码最后才怀疑模式。6.1 从 Windows 拖过来的文件为什么 $ 失效把文件用cat -A看一眼就能确诊cat -A config.ini | head -3如果每行末尾出现^M$说明这一行是\r\n结尾。^M就是回车符\r。此时grep ^\[server\]$匹配不到因为实际内容是[server]\r$锚定的位置在\r之后。三种处理方式看你的场景# 临时搜索把 \r 写进模式 grep -P ^\[server\]\r$ config.ini # 一次性清洗转换整个文件 sed -i s/\r$// config.ini # 长期方案交给工具 dos2unix config.ini我强烈推荐第三种。手工sed替换在文件本身就含\r语义时极少数二进制格式会破坏内容而dos2unix会做检测行为更可靠。另外在 Git 层面给仓库加.gitattributes里写* textauto eollf能从源头堵住这个问题比事后清洗划算得多。6.2 GBK 文件里的中文搜索第二个高频坑是编码。在 UTF-8 的终端里用 UTF-8 编码的中文去搜一个 GBK 编码的文件结果必然是空——两者在字节层面就完全不同。先用file确认编码file -i old_data.csv # 输出类似old_data.csv: text/plain; charsetiso-8859-1如果确认是 GBK两条路。临时搜索用iconv转管道iconv -f GBK -t UTF-8 old_data.csv | grep 订单编号需要反复搜索就先转成文件一劳永逸iconv -f GBK -t UTF-8 old_data.csv old_data.utf8.csv grep 订单编号 old_data.utf8.csv还有一种情况更隐蔽文件本身是 UTF-8但里面混入了少量非法字节序列比如从某处复制粘贴带进来的。这时候 GNU grep 会打印grep: old_data.csv: binary file matches或者直接跳过那些行。加-a可以把文件当纯文本处理把含非法字节的行也输出出来grep -a 关键词 mixed.txt反过来如果你在扫描大量二进制文件只想跳过它们用-I明确告诉 grep 忽略二进制文件输出会干净很多。6.3 一个容易被忽略的 locale 副作用-i忽略大小写这个选项行为受 locale 影响。在Clocale 下它只折叠 ASCII 的 A-Z在en_US.UTF-8下它还会处理带音标的字符在tr_TR.UTF-8土耳其语下字母 I 的大小写折叠规则和英文不同可能导致意外结果。所以当你在容器里跑脚本镜像用了Clocale而开发机上用zh_CN.UTF-8同一个grep -i可能给出不同结果。要保证可复现就在脚本里显式设定export LC_ALLC这个操作同时还能提速一举两得。代价是放弃多字节字符的大小写处理如果你的数据里确实有非 ASCII 的大小写需求那就不要设但要意识到环境差异的存在。7. 计数、去重与统计筛完之后的事grep只负责筛统计靠管道。这一段是运维报表和日志分析的日常。7.1 -c 数的到底是什么grep -c数的是命中的行数不是匹配出现的次数。一行里出现了 10 次关键词-c也只算 1。这个区别在统计接口调用量时会带来巨大偏差。想数出现次数用-o把匹配片段单独输出每一段占一行再交给wc -l# 行数有多少行提到了 timeout grep -c timeout app.log # 次数timeout 一共出现了多少次 grep -o timeout app.log | wc -l-c本身也有个好用的冷门写法grep -c file会输出文件的总行数空模式匹配所有行等价于wc -l。在某些只有 grep 可用的极简环境里能应急。7.2 用 -o 和 sort/uniq 拼出排行报表-o配合管道能做出相当实用的统计。比如统计访问日志里出现次数最多的 IPgrep -Eo ^[0-9]{1,3}(\.[0-9]{1,3}){3} access.log \ | sort \ | uniq -c \ | sort -rn \ | head -20拆开看每一步的职责-o只留 IP 片段sort把相同 IP 排到一起这是uniq能正确去重的前提uniq -c统计连续重复行sort -rn按数值倒序head -20取前 20。顺序不能乱尤其是sort必须在uniq之前否则计数会碎成多段。统计错误级别的分布也是同样的套路grep -Eo ^(ERROR|WARN|INFO|DEBUG) app.log | sort | uniq -c | sort -rn一次就能看出日志里的级别构成对判断系统健康状况很有参考价值。7.3 和 awk 接力把数据变成字段当需要按某个字段统计时grep负责筛选awk负责切列分工明确# 统计各接口的平均耗时假设格式接口名 耗时ms grep cost app.log \ | awk -Fcost {print $2} \ | awk {sum$1; n} END {if(n0) printf avg%.2f ms, count%d\n, sum/n, n}这类组合在处理性能日志时非常高效。关键在于grep的正则要保持宽松只做粗筛把精确解析留给awk。反过来如果grep的模式写得太严漏掉一些格式略有差异的行统计结果就会偏差而你很难发现。8. 一份按场景归类的命令清单最后给一份我自己的速查表按使用场景而不是字母顺序排列。都是长期用下来最顺手的写法。场景命令关键说明字面量搜索grep -F -- str file-F关正则--防短横线误解析忽略大小写grep -i str file受 locale 影响脚本里固定LC_ALL显示行号与上下文grep -n -C 3 ERROR app.log-C前后各 3 行只列文件名grep -rl str ./src评估影响面时先跑这个排除目录递归grep -rn --exclude-dir.git str .只对递归生效全词匹配grep -w id file挡掉userId、grid计数行数grep -c str file是行数不是次数计数次数grep -o str file | wc -l配合-o判断有无grep -q str file命中即退出大文件首选限定命中条数grep -m 5 str file按文件生效多模式grep -E A|B|C file或grep -e A -e B -e C反向筛选grep -v DEBUG app.log排除噪音行多模式反向grep -vE DEBUG|TRACE app.log一次排除多种处理二进制grep -a str bin-I则跳过二进制安全传给 xargsgrep -rlZ str . | xargs -0 cmd防空格与换行加速大文件LC_ALLC grep -F str huge.log单字节快速路径我个人最想强调的还是第 1 节那件事把grep当成按行判定的正则筛子而不是查找字符串的工具。一旦你接受这个模型-F、-E、-o、-c、-m、-q这些选项就不再是一堆需要死记的开关而是同一个模型上的自然推论。至于模式里的转义、编码、换行这些坑本质都是在提醒你——grep 看到的永远是字节不是你以为的字符。排查时先看cat -A和file -i比对着屏幕反复改正则要快得多。