grep替代工具大盘点：rg、tgrep、rawgrep、zg怎么选？

我最早开始真正研究 grep 的替代工具，是某次在几个 GB 的仓库里跑grep -rn等结果等到咖啡都凉了的时候。那个仓库有几十个目录、上万份代码文件、海量日志和静态资源，一条简单的文本匹配居然要扫十几秒。换用rg（ripgrep）之后，第一次运行基本在 1 秒内出结果。那一瞬间我就明白：不是老命令不行了，是我们手里早就有了更顺手的家伙，只是很多人还没切换过来。

这次想写一篇关于 grep 工具家族的大盘点：rg、tgrep、rawgrep、zg。它们解决的是不同层次的问题，有代码搜索、有结构化文本检索、有原样匹配需求，还有压缩文件里的搜索。通读一遍，你至少能学会两件事：一是知道什么场景该用哪个工具；二是能从底层原理出发，真正理解为什么这些工具有快慢和“搜得到/搜不到”的差别。

1. grep 的家族生态：为什么要重新审视一个 1972 年的老命令

1.1 从 ed 到 grep：命令为什么叫 grep

先说个冷知识。grep 这个名字来源于ed编辑器里的一个全局正则打印命令：g/re/p，也就是 global / regular expression / print 的缩写。它的使命从一开始就很明确：在输入文本里按正则表达式查找，把匹配的行打印出来。

这套逻辑非常简单，所以由它衍生出来的一整条工具链都保持着惊人的一致性：输入一行文本，判断是否匹配，输出匹配的行，返回退出码。退出码 0 表示找到匹配，1 表示没找到，2 表示遇到错误。这个约定到今天依然是所有 grep 系工具共同遵守的基础规则。

问题在于，grep 诞生于磁带和慢速终端的年代，它当时的很多默认行为，比如不递归搜索、不区分隐藏文件、不做多线程优化，在现在的开发场景里已经变成了需要反复回避的痛点。于是才会有后来百花齐放的 grep 替代品：ack、ag（the_silver_searcher）、rg，以及各种专注特定场景的专用工具。

1.2 grep 的三大不顺手：性能、规则、默认行为

把 grep 在日常使用中的不舒服总结起来，基本是三件事。

第一是性能。GNU grep 本身其实已经相当快，单文件搜索时它的类 BM 算法和大量 SIMD 优化非常优秀。但普通用户常用的grep -r是单线程递归扫描，每打开一个文件都要做一次完整的状态初始化，在文件数特别多、文件体积特别大的场景下，性能远远不如能并行扫描的现代工具。

第二是规则。普通 grep 默认不会自动读取.gitignore，不会自动跳过.git目录，也不会自动识别二进制文件与文本文件。于是你在项目里搜某个函数名，出来的结果里夹着一堆历史快照、编译产物、node_modules 甚至图片文件，需要额外拼一堆--exclude-dir参数才能勉强过滤掉。

第三是默认行为不够稳。不同 Linux 发行版自带的 grep 版本可能不同，有些默认支持 PCRE（用-P开启），有些没有编译进来；在多字节字符的处理上，locale 设置不同也会影响匹配结果。这些“环境差异”在脚本里特别容易埋雷。

1.3 大盘点思路：rg、tgrep、rawgrep、zg 分别补了什么

既然 grep 不是万能的，那这一批新工具各自补的都是哪块短板？

rg补的是“大规模代码/文件检索”的短板，用并行、内存映射、规则集把搜索速度和准确性拉到极致。

tgrep补的是“结构化文本层级检索”的短板，它对应的不是一行行的字符串，而是一个个有层级结构的节点，你可以直接按“父节点是 A、子节点是 B”这种条件去搜索。

rawgrep补的是“默认行为堆叠太多”的短板，它在概念上强调关闭各种附加逻辑，让输入和输出尽量原样，适合在调试正则或对比版本差异时有强迫症的人。

zg（实际使用中通常写作zgrep）补的则是“压缩文件不解压就能搜”的短板，它把解压和 grep 组合成一条流水线，让你直接在大批量压缩日志里做检索。

后面几节我一个一个展开讲。

2. 代码搜索首选：rg（ripgrep）为什么能成为新默认

2.1 ripgrep 的性能怎么来的

先给结论：rg是目前我在日常项目里使用频率最高的检索工具，没有之一。它是用 Rust 写的，但语言本身只是加分项，真正让它快的原因主要有三个。

第一个原因是并行遍历。rg默认会按 CPU 核数并行扫描文件，文件内容读取和正则匹配分布到多个工作线程里，在大目录下效率提升是数量级的。第二个原因是智能跳转。它默认遵守.gitignore、跳过隐藏目录和隐藏文件、跳过二进制文件，绝不浪费一滴性能在无关数据上。第三个原因是内存映射优化。对超大文件，它会用操作系统的内存映射机制做高效读取，而不是把整个文件塞进用户态内存里慢慢啃。

这三板斧合在一起，效果非常明显。我在一个 50 万行代码、混合了图片和日志的仓库里测试过：grep -r 'orderId' .要跑 6 秒多，rg 'orderId' .基本上是 0.3 秒内出结果，而且输出的结果还更干净，因为不会被编译产物和二进制文件干扰。

2.2 日常命令速查表：从简单匹配到组合过滤

rg 的入门成本极低，因为 90% 的用法和 grep 是重叠的。下面这几个命令是我每天都在用的，可以直接抄：

# 常规递归搜索，输出行号和文件名 rg "OrderService" . # 只看文件名，不显示具体匹配行 rg -l "error" src/ # 忽略大小写 rg -i "orderid" . # 全字匹配，避免把 orderIdxxx 也搜出来 rg -w "order" . # 限定文件类型，比如只看 Java 文件 rg -t java "List<Order>" . # 显示匹配行的上下文 rg -C 3 "exception" logs/backend.log # 反向匹配，显示不含关键字的行 rg -v "^#" nginx.conf # 计数统计 rg -c "error" logs/

和 grep 不太一样的地方在于，rg默认就是递归搜索当前目录，不需要手动加-r；输出有颜色高亮，终端下阅读体验好很多；文件名和行号也默认带上。

2.3 常用参数与正则注意事项：为什么 -P 和 -uuu 要谨慎用

如果你只把 rg 当成“跑得快的 grep”那就太浪费了。它有一批参数专门用来处理 edge case。

第一个是-uuu。-u在 rg 里不是“unique”的意思，而是“反忽略”的等级：一个-u不读.gitignore，两个-u再搜索隐藏文件，三个-u连二进制文件也一并扫描。我见过不少人在网上提问“rg 怎么搜不了隐藏文件”，其实答案不是-a，而是-uu。要注意这个参数的使用场景，一般只在临时排查时用，日常搜索加上它只会让结果变脏。

第二个是-P（也就是--pcre2）。rg 默认用 Rust 自带的 regex 引擎，不支持反向断言这类语法。如果你有一个习惯了 PCRE 的正则表达式，比如(?<=key=)\d+，直接丢给 rg 会报错。加上-P之后 rg 会切换到 PCRE2 引擎，功能更全，但性能也有一定下降。我的经验是：日常简单匹配用默认引擎，临时做复杂断言才开 PCRE2。

第三个是--type-add。有时候项目里某些文件扩展名不在内置类型表里，比如运维用的.tpl模板想让 rg 当成 html 处理，可以这样：

rg --type-add "web:*.tpl" -t web "csrf_token" .

这个配置也可以写进.ignore或全局配置文件里，不需要每次敲。

还有一个实际中很容易踩的坑：rg 的-S（--smart-case）默认是开的。意思是如果模式里有大写字母，就区分大小写；如果模式全是小写，就不区分大小写。这个行为很智能，但也会让在脚本里的结果变得“不稳定”。如果你就是在写一个严谨的 CI 检测脚本，建议显式用-s强制区分大小写，别依赖 smart-case。

2.4 什么时候还要回头用 grep

说了 rg 这么多好话，也得给老将留个位置。你至少应该把 grep 的这几个不可替代的场景记下来：

第一，环境不可控的服务器上。很多老系统没有预装 rg，你也不能为了搜一个文件就去装工具包，这时候系统自带的 grep 是唯一选择。第二，脚本可移植性要求高的情况。POSIX 规范里只保证 grep 存在，rg 不保证。写给别人的脚本，或者部署到受限容器里的脚本，用 grep 更安全。第三，单文件小规模搜索。文件很小的时候，grep 和 rg 的差距可以忽略不计，而 grep 的生态兼容性更好。

另外也提一嘴ag和ack。ag（The Silver Searcher）是 rg 之前很流行的选择，它的思路和 rg 几乎一样，但项目已经基本停止迭代，新项目直接选 rg 就好，不用再走回头路。ack是 Perl 写的老牌工具，功能不差，但在大目录下性能比 rg 差两三个量级，偶尔兼顾 Perl 正则习惯的人还在用，整体上是明日黄花。

3. tgrep：面向结构化文本的层级检索

3.1 tgrep 是什么，和 grep 有什么不同

很多人第一次听到tgrep会下意识认为它只是“快一点的 grep”，实际上这个名字在开源领域里更多指代 Tree grep，也就是“树结构的 grep”。它最早是语言学语料库领域用来搜索句子语法树的工具，后来慢慢衍生出一些面向 XML、JSON 和其他结构化文本的检索实现。

它和普通 grep 的本质区别在于：普通 grep 针对的是“行”，一行是一个不可拆分的字符串；tgrep 针对的是“节点”，输入文本被解析成树，每一个节点都有类型、文本、父子关系和兄弟关系，你可以按结构来写搜索条件。

举个通俗的例子。普通 grep 想找“某本小说里所有对话”，只能写grep '“'，把每一行里带左引号的行全列出来。但如果文本已经被标成了段落和引号节点，tgrep 就能直接问“哪些引号节点位于段落节点之下”，过滤条件比行级匹配精确得多。

在实际工程里，我见过三类特别适合 tgrep 思路的用法：一是 NLP 领域检索句法树。二是大规模配置文件里按父子层级定位设备配置。三是 JSON 日志里按对象路径去匹配内容。

3.2 一套更通用的层级检索思路：不靠工具名，靠场景

因为“tgrep”这个名字有专门的学术含义，日常后端项目里直接把它拿来当命令用的情况反而不多。我更建议你把它理解成一组能力，而不是死记某个二进制名字。在大多数生产环境里，你其实可以用现成的工具组合出“类 tgrep”的效果。

比如搜索 JSON 日志里的特定字段层级，最顺手的不是 grep，而是先拍平再过滤：

cat app.log | jq -r '.. | objects | .level? // empty' | grep -E "ERROR|WARN"

这里jq负责把 JSON 的嵌套层级转成一行行的纯文本，再用 grep 做行级匹配。相当于把一个树形结构先做了投影，再把投影结果交给传统 grep。

再比如处理 XML 文件，直接对行做 grep 很容易被标签格式、命名空间干扰，更可靠的做法是用xmllint --xpath先摘出要查的节点：

xmllint --xpath '//server[@port="8080"]/name/text()' deploy.xml

这个写法的检索依据是 XML 的节点结构，而不是字符串表面，正是 tgrep 类工具的强项。如果你经常处理 HTML/XML，还可以考虑用 Python 的 lxml 写一段极短的解析脚本，比硬拼正则稳得多。

3.3 想要真正的 tgrep 命令，去哪里找

如果你确实就是想玩一下真正的 Tree grep 工具，有两个方向可以查：一个方向是 NLP 语料库常用的 tgrep，它有一套专门的语法，例如用>表示“父节点为”，<表示“子节点为”，搜索条件可以写成类似“找到所有动词短语，且它的直接父节点是句子节点”这种形式。另一个方向是部分开源项目里自带的“结构化 grep”命令，比如针对 AST 扫描的 semgrep，某种意义上也可以看作“针对代码语法树的 tgrep”。

我的建议是，不要执着于找一个所有场景通用的 tgrep 二进制。把“结构化层级检索”这个思维装进脑子里，平时用 jq、xmllint、semgrep 按场景组合，就已经能解决绝大部分问题。这也符合工具发展的规律：结构越复杂，越不可能靠单一通用命令搞定一切。

4. rawgrep：关闭智能，回到“原样匹配”的世界

4.1 所谓 raw，到底 raw 在哪

这几年文本检索工具的趋势是越来越“聪明”：自动忽略不受版本控制的文件、自动过滤二进制、自动压缩输出。大多数情况下这是好事，但也有一批人踩过“智能”带来的坑：明明文件就在那里，rg 就是不搜它，因为里面的规则太多了，你根本想不到是哪一个默认开关拦住了结果。这时候，你需要的可能是一个接近 raw 行为的工具或配置。

我这里提到的rawgrep，在开源软件库里其实有两个来源：一个来源是某些 Unix 工具爱好者在早期 grep 源码基础上做的最小化重写，目的是让行为尽量贴近最初“g/re/p”的朴素逻辑；另一个来源是把 grep 的“额外参数全关掉”这个操作固化成一种习惯。核心思想是一致的：关闭一切附加行为，让输入、匹配、输出三者之间不再有隐形的中间规则。

这也是我特别想强调的一点：rawgrep 的价值不在于“快”，而在于“确定”。当你在调试一个诡异的正则问题，或者需要对比两份文件在纯文本层面到底差在哪时，一个不友好的“智能工具”反而会帮倒忙。raw 模式给你的是一种可复现、可解释的行为。

4.2 用现成工具构造一个 raw 模式

好消息是，你不需要真的去编译一个 rawgrep，光靠 ripgrep 自带的反智能参数，就能模拟出足够“raw”的行为。我平时是这样用的：

# 真·raw 模式：不读 ignore 规则、搜隐藏文件、二进制当文本、不做 smart case alias rawrg='rg -S --no-ignore --hidden --no-require-git -a --no-heading'

拆解一下这里每个参数的用意。--no-ignore表示不读.gitignore、.ignore等规则文件；--hidden表示搜索隐藏文件；-a表示把二进制文件也当文本处理；--no-require-git表示即使不在 Git 仓库里也照常搜索；--no-heading去掉分组输出，让每行输出只有文件路径加匹配内容，方便继续喂给下一级命令做文本处理。

如果你习惯用 GNU grep，也有对应的朴素姿势。这里的关键是把默认的智能行为显式关掉：

# 不递归、不做文件类型过滤、二进制也直接扫、不读任何 rc 文件 grep -a --no-messages --exclude-dir=/.git -n "pattern" .

对了，很多 grep 和 rg 都会自动跳过符号链接，想彻底 raw 就要在搜索前用find -L做一次解引用，或者给 rg 加--follow。

关于 raw 模式，有一个经典使用场景：线上排查时，你明明看到tail -f server.log里滚过了一行包含关键 UUID 的错误，但用rg "UUID" logs/搜索所有日志却什么都搜不到。这时候不要怀疑眼睛，先检查日志文件是不是放在了.gitignore认识的某个目录下。用 raw 模式扫一遍，结果大概率就出来了。

4.3 适合 rawgrep 的实战场景，以及它的边界

我总结下来，rawgrep 类行为在三种场景里是真正发挥价值的。

第一种是跨文件内容对比。比如你想确认线上某个部署包里的配置和源码仓库里的配置是不是一致，直接对两批文件跑 raw 搜索，把结果 dump 出来做 diff，可以排除掉版本控制系统忽略文件造成的假差异。

第二种是二进制文件里的可读字符串提取。在二进制包里找明文 IPv4 地址、URL、密钥前缀等，普通 grep 会因为检测到二进制而打住，raw 模式配合strings命令往往能直接命中。

第三种是写自动化校验脚本。脚本里需要保证“搜索逻辑只受显式参数影响”，不希望某一天团队有人往.ignore文件里加一行规则导致搜索行为变化。这时候 raw 方式的确定性就是可维护性。

但边界也很明显：raw 模式没有智能排除，扫描整个大目录时会产生大量噪音，而且输出结果不一定按照你预期的编码展示。它的定位是“最后手段”和“调试工具”，日常开发主力仍然是 rg。

5. zg / zgrep：压缩文件里的检索专家

5.1 zgrep 的原理和基本用法

“zg”这个写法在日常场景里，大家更多使用的是zgrep。它做的事情可以概括成：不用手动解压，直接在 .gz 压缩包里执行 grep 搜索。

原理并不复杂。gzip 压缩的文件经过gzip -dc命令会输出原始内容到标准输出，zgrep本质上就是把这一步和grep通过管道串起来的封装。它内部会逐个解压文件，再把解压后的内容喂给真正的 grep，然后把匹配结果打上文件名前缀输出。优势在于你不需要在磁盘上生成临时解压文件，对一个几十 GB 的压缩日志包也能按需读取。

基本用法和 grep 非常接近：

# 搜索单个 gz 压缩包 zgrep -n "ERROR" app.log.2025-01-01.gz # 搜索多个压缩包 zgrep -i "exception" app.log.2025-01-0*.gz # 加上上下文行数 zgrep -C 3 "NullPointerException" backend.log.2025-01-02.gz

注意，zgrep的-E表示扩展正则，-F表示固定字符串，这跟 grep 的参数完全一致，你不需要重新学一套语法。

5.2 多类压缩格式与对应命令

压日志的工具五花八门，好在不同压缩格式都有对应的 grep 变体：

这些命令的行为模型都一样：把“解压到标准输出”和“grep 搜索”串起来，返回值和普通 grep 保持一致。只是底层解压算法不同，性能差异会体现得很明显。

如果日志经过了多级压缩，比如.tar.gz里套了多个小文件，用zgrep也不是不行，但更推荐的做法是先列出压缩包内容，再按需选择目标文件：

tar tzf full-backup-2025-01.tar.gz | head -50 tar xOzf full-backup-2025-01.tar.gz path/to/access.log | grep -E "403|404"

tar xOzf可以把压缩包里的指定文件直接解压到标准输出，配合 grep 或 head 用，既省磁盘又不浪费全量解压时间。

5.3 压缩日志检索的生产级姿势

在实际日志聚合系统不完善的团队里，压缩日志检索是每次排障必做的脏活。我总结了一套相对不踩坑的操作流程。

第一，先确认文件名模式。很多团队的日志轮转策略是app.log、app.log.2025-01-01.gz、app.log.2025-01-02.gz这样递增。检索时间范围的第一件事是先ls -lh看看哪些压缩包落在这个时间窗口内，避免把后续的搜索命令拉到整个目录所有文件上。

第二，用管道聚合而不是多次手工搜索。比如查某一小时内所有 5xx 错误，可以这样：

zgrep -h "2025-01-07T10:" app.log.2025-01-07*.gz | grep -E "HTTP/(1\.[01])\" [5-9][0-9][0-9]"

其中-h表示不显示文件名前缀，因为这一轮你关心的是纯日志内容，文件名等下一轮再区分。

第三，善用合并参数。需要多个关键词同时匹配时，不一定要写多个管道，直接让 zgrep 用扩展正则做一次匹配，速度会快很多：

zgrep -E "ERROR|OutOfMemory|Connection refused" app.log.2025-01-07*.gz | head -200

一次性把候选行拉出来，再通过上下文参数做精细定位，比一步步管道过滤更容易保留现场信息。

第四，面对超大 gz 时，别急着裸奔 zgrep。先检查压缩包本身有没有损坏，否则解压到一半会返回一堆莫名其妙的错误：

gzip -t app.log.2025-01-07.gz

确认没问题后再搜索。这道检查对动辄几十 GB 的生产日志尤其重要。

5.4 大坑与小抄：zgrep 常见的翻车点

使用 zgrep 最容易翻的第一个坑是“管道里二次搜索太慢”。假设你要在一个 10GB 的压缩日志里搜某个 traceId，再用这个结果反查另一个关键词，如果写法是zgrep 'traceId123' huge.gz | grep 'timeout'，那么第一个 zgrep 会把所有包含 traceId123 的行都解压并输出，其中绝大多数你并不关心。更高效的做法是直接写一个更精确的正则，让 zgrep 一次性过滤：

zgrep -E "traceId123.*timeout|timeout.*traceId123" huge.gz

第二个坑是退出码。zgrep在没有匹配时返回 1，在有部分文件损坏时可能返回 2，这本来是很好的脚本友好行为。但如果你在没加set -o pipefail的 shell 脚本里使用zgrep ... | head，管道退出码会被 head 覆盖，脚本的后续判断逻辑可能失效。记得在关键脚本里显示处理退出码。

第三个坑是编码问题。压缩日志经常是从 Windows 服务器导出的 GBK 编码文件，直接 zgrep 搜中文会什么都搜不到。正确处理是先把解压流做编码转换再匹配：

zgrep -h "" app.log.2025-01-07.gz | iconv -f GBK -t UTF-8 | grep "订单过期"

注意这里用了zgrep -h ""来清空文件名前缀，同时利用 zgrep 只负责解压输出，把真正的匹配逻辑交给 iconv 后面的 grep。

第四个坑是性能认知。gzip 的解压是 CPU 密集型操作，用 zgrep 在多个大文件上搜索，瓶颈往往不在 grep 而在解压。如果机器上有pigz（并行 gzip），可以这样提速：

# 用 pigz 并行解压再搜索 pigz -dc app.log.2025-01-07.gz | grep --color=never "1f3870be274f6c49b3e31a0c6728957f"

在四核以上的机器上，这个组合在很多场景里比原生 zgrep 快不少。

6. 高频问题与排查实录

6.1 rg 搜不到内容，但 grep 能搜到，怎么办

这是我在社区里被问到最多的问题，没有之一。明明文件里肉眼就有那个字符串，rg却一声不吭，用grep反而能搜出来。遇到这种情况，按下面的顺序排查基本百发百中：

第一步，确认是否被 ignore 规则拦住了。在项目根目录跑：

rg --files --no-ignore | grep "目标文件"

如果带--no-ignore能看到文件，不带就看不到，说明是.gitignore或.ignore挡住了。

第二步，确认是否因为文件是隐藏文件或二进制文件。加-uuu再搜一次，如果结果出现，说明默认过滤生效了。

第三步，确认文件类型过滤是否把目标文件排除掉了。如果你用了-t java却去搜一个.sql文件，那当然搜不到。用--type-add补充类型，或者干脆去掉-t参数。

第四步，想想正则对不对。rg 默认的 Rust regex 语法和 PCRE 有差异，如果你拿一个带后行断言的 PCRE 正则去跑，rg 会直接报错而不是静默失败。但如果你用的是--pcre2，个别转义写法也会结果不同。最简单的验证方法是用grep -P交叉跑一下。

这个方法论不仅适用于 rg，也适用于任何“智能”的搜索工具。搜不到东西时，第一反应不是怀疑数据，而是先问“它的默认行为过滤了什么”。

6.2 grep 中文乱码与编码问题

中文日志乱码是另一个高频痛点。直接grep "错误" file不出来，或者输出的中文全是乱码，大概率不是正则写错了，而是编码不匹配。Linux 文本文件常见 UTF-8，而很多老应用输出 GBK/GB18030。

遇到这种情况，先看文件编码：

file -i app.log

如果显示charset=iso-8859-1或charset=unknown，可以尝试用 iconv 转码后再搜。比如把 GBK 转成 UTF-8：

iconv -f GBK -t UTF-8 app.log | grep "订单过期"

如果文件实在太大，用iconv全量转换太慢，可以先按行采样，确认编码后只转换需要的窗口范围，比如用sed -n '100,200p'切片再转码。

还有一个隐藏问题：locale 环境变量没设好，grep的中文匹配时可能因为 locale 不匹配导致性能急剧下降。在容器里遇到 grep 匹配特别慢，先看环境：

echo $LANG $LC_ALL

如果是空值或 POSIX，建议显式设置export LANG=C.UTF-8再搜。

6.3 正则引擎不同导致的差异

正则表达能力是 grep 系工具最容易“同词不同义”的地方。GNU grep 的默认基础正则（BRE）和扩展正则（ERE）在细节上跟 PCRE 差很多。比如，在 BRE 里+是普通字符，表示一次或多次要写成\+；在 ERE 和 rg 里+就是量词。同一段正则放到不同工具里结果不同，是非常正常的。

给一个最小对比表：

如果你在写跨工具复用的正则，最稳妥的策略是统一用固定字符串-F，或者严格按 ERE 语法写，然后所有工具都走-E。避免在默认 BRE 和 PCRE 之间反复横跳。

6.4 想提升速度，先学会给文件“减负”

搜得慢有时候不是工具不行，是你让它搜了太多不该搜的文件。优化顺序我一般这样排：

第一步，缩小范围。能指定目录就不搜全仓库，能用文件名后缀过滤就不裸搜。

第二步，排除无用目录。在 rg 的全局配置里，我永远会加一行：

# ~/.config/ripgrep/ripgrep.conf glob !.git !node_modules !dist !build !vendor

这样任何一次搜索默认都不碰这些目录，速度和结果噪音同时改善。

第三步，控制输出量。只要不需要看全部匹配行，就优先用-l（只列出文件名）、-c（只统计次数）或-m 20（最多显示 20 行）。

第四步，合理利用并行。多核机器上给 zgrep 类工具换用 pigz 做底层解压，给 rg 就不用管了，它默认多线程。

这一套组合下来，绝大多数搜索都能达到“手指刚离开回车，结果已经出来了”的状态。

7. 选型速查与我的使用习惯

7.1 四个工具的定位差异

最后把这几个工具放到一起做个速查，方便你按场景直接对号入座：

四者绝不是互相替代的关系。rg 是我日常的主力；当需要处理结构化数据时，我会想起 tgrep 的思路并灵活切换到 jq 或 xmllint 这类工具；当搜索行为变得不可捉摸时，rawgrep 式的“裸奔配置”能帮我把问题拉回可控范围；只要涉及压缩文件，zgrep 就是绕不开的伙伴。

7.2 我给自己配置的常用命令

我把自己平时的一套配置贴在下面，都是 shell 别名和函数，你可以按习惯微调：

# 代码搜索主力 alias q="rg -n --hidden -g '!.git' -g '!node_modules'" # 只看文件名 alias ql="rg -l --hidden -g '!.git' -g '!node_modules'" # raw 模式，查隐藏文件、二进制也搜 alias rrg="rg -uuu -a --no-heading" # 普通 grep 保持颜色 alias g="grep --color=auto -n" # 搜压缩日志 alias zg="zgrep -n --color=auto" # 并行解压搜日志 pigz_log_search() { local pattern="$1" shift for f in "$@"; do pigz -dc "$f" 2>/dev/null | grep --color=never "$pattern" | sed "s|^|$f:|" done }

有了这些别名，日常进入项目后基本就是q加关键词的肌肉记忆。而pigz_log_search这个函数解决了一个 zgrep 不能做并行解压的问题，实测在压缩日志比较多的机器上能省不少时间。

7.3 最后一个小建议：把“搜索”当工程来对待

说了这么多，我最想传达的一句话是：搜索不是一个“敲命令这么简单”的动作。一次好的搜索结果，取决于你对文件结构的理解、对编码和忽略规则的敬畏、对正则引擎差异的敏感，以及一点点把工具组合起来的想象力。

我个人踩过无数次坑之后，最受益的一个习惯是：凡是超过 10 秒的搜索，我都会花半分钟想想“是不是我让他搜的东西太多了”；凡是搜不到的时候，我都会先检查“是什么智能行为把它挡住了”。你要是也能养成这种习惯，那不管是 grep、rg、tgrep 还是 zgrep，在你手里都会变成趁手的兵器。