1. grep 的脾气：一台只认行不通融的文本筛子
很多人第一次学 Linux 命令，都是从grep开始的，理由也很简单——"查找字符串"这件事听起来没有门槛。但真正在生产环境里用上三个月你就会发现，grep相关的故障单能占到命令类问题的一大半：明明文件里写着这个字符串，就是搜不出来；明明只想看日志里的一行，结果刷屏几千行；明明写进了脚本，退出码却死活不对。问题不在于命令难，而在于绝大多数教程把grep讲成了"搜索工具"，而没有讲清楚它真正的行为模型：grep是一个逐行做判定的筛子，它的输入是"行"，输出也是"行"，中间的判定逻辑是一段正则。
这三句话决定了它的全部使用方式。因为它按行处理，所以它天然不擅长跨行匹配；因为它的判定标准是正则而不是字面量，所以关键词里的.、*、[、$都有特殊含义；因为它的输出单位是行，所以你想要"匹配次数"而不是"匹配行数"时，必须额外加参数。把这些前提吃透，后面那些看起来零散的选项就有了统一的解释：-o是为了把"行"拆回"匹配片段"，-A/-B/-C是为了把"行"扩展成"上下文块"，-c是为了把"行"压缩成"数量"，-l是为了把"行"降级成"文件名"。它们全都是在同一个行为模型上做的变形。
这篇文章不谈命令手册式的罗列。我想按照真实排查路径来组织：一个做后端运维或者写脚本的人，从敲下第一条grep开始，会遇到哪些判断点、哪些坑、哪些必须记住的取舍。如果你刚接触 Linux，可以把它当作一份带解释的速查；如果你已经用了几年，可以直接跳到第 4 节往后，那部分是我自己在线上环境里踩出来的经验。
1.1 一次调用里，grep 实际做了三件事
抛开所有选项，grep的执行过程可以拆成三步。第一步是取样：从文件、标准输入或者递归目录里拿到一批"行"，每一行的边界默认是换行符\n，如果你加了-z，边界就变成\0——这个选项在处理包含换行的文件名时特别有用。第二步是判定：把每一行的内容（注意，默认不包含行尾的换行符）喂给模式去做匹配，匹配上了就标记为命中。第三步是输出：命中的行被原样打印到标准输出，如果加了-n就带行号，加了--color=auto就把命中片段染色。
这里有一个容易被忽略的细节：判定时被匹配的字符串不含行尾换行符，但它包含行尾的\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.txt，shell 会试图展开变量$1和字符串 "00"，$1为空，模式就变成了 "00"，结果自然是错的。正确写法是grep '\$100' price.txt或者grep -F '$100' price.txt。
第二，变量作为模式时，引号的选择会改变语义。假设p="a b"：
grep $p file # 等价于 grep a b file，b 被当成文件名 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 'debug=true' ./conf) # 安全：用 NUL 分隔传递 grep -rlZ 'debug=true' ./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-dir='node_modules' \ --exclude-dir='venv' \ 'DATABASE_URL' .它们的行为有两处细节值得记住。第一，--include和--exclude是按文件名匹配的，支持*、?、[]这些 glob 通配符，但不支持**这种递归通配。所以--include='*.py'有效，--include='src/**/*.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 指向 B，B 又指回 A），-R会陷入无限递归。GNU grep 加了一个-D选项来控制对设备、FIFO、套接字的处理，但在循环软链上并没有自动保护。所以我的习惯是：用-R之前先find . -type l看一圈有没有环，或者在容器这种可控环境里才放心用。
5.3 大文件与海量小文件的提速手段
同样的搜索，写法不同，耗时可差几十倍。几个实测有效的加速手段：
# 关掉本地化，字符处理走单字节快速路径 LC_ALL=C 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 'needle'LC_ALL=C的效果最容易被低估。在 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里写* text=auto eol=lf，能从源头堵住这个问题，比事后清洗划算得多。
6.2 GBK 文件里的中文搜索
第二个高频坑是编码。在 UTF-8 的终端里用 UTF-8 编码的中文去搜一个 GBK 编码的文件，结果必然是空——两者在字节层面就完全不同。
先用file确认编码：
file -i old_data.csv # 输出类似：old_data.csv: text/plain; charset=iso-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_ALL=C这个操作同时还能提速，一举两得。代价是放弃多字节字符的大小写处理，如果你的数据里确实有非 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配合管道，能做出相当实用的统计。比如统计访问日志里出现次数最多的 IP：
grep -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 -F'cost=' '{print $2}' \ | awk '{sum+=$1; n++} END {if(n>0) 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则跳过二进制 |
| 安全传给 xargs | grep -rlZ 'str' . | xargs -0 cmd | 防空格与换行 |
| 加速大文件 | LC_ALL=C grep -F 'str' huge.log | 单字节快速路径 |
我个人最想强调的还是第 1 节那件事：把grep当成"按行判定的正则筛子"，而不是"查找字符串的工具"。一旦你接受这个模型，-F、-E、-o、-c、-m、-q这些选项就不再是一堆需要死记的开关，而是同一个模型上的自然推论。至于模式里的转义、编码、换行这些坑，本质都是在提醒你——grep 看到的永远是字节，不是你以为的字符。排查时先看cat -A和file -i，比对着屏幕反复改正则要快得多。
