rg 使用教程：为什么现在很多人用 ripgrep 替代 grep

最近在使用 GitHub Copilot 的时候，我经常看到它调用 rg 来做文本匹配和代码搜索，所以顺手把 rg 和 grep 的区别重新梳理了一遍。

在 Linux 上查字符串，很多人第一反应还是 grep。但如果你经常要在项目目录里递归搜代码、过滤文件类型、跳过 node_modules 或 .git，那 rg 也就是 ripgrep，通常会更顺手。

grep 当然还很有用，尤其在 shell 管道、标准输入处理和兼容老脚本时非常稳定。但如果场景是“在一堆源码和日志里快速找东西”，rg 往往更快、输出更清晰，默认行为也更适合开发者。

这篇文章就只做一件事：用实际命令把 rg 讲清楚，并直接和 grep 做一轮对比。

一、rg 是什么，和 grep 有什么关系

rg 是 ripgrep 的命令名，本质上也是一个文本搜索工具。

它和 grep 的核心目标一样，都是在文本里找匹配内容，但默认使用体验有几个明显区别：

1. rg 默认递归搜索当前目录
2. rg 默认会遵守 .gitignore
3. rg 默认会跳过二进制文件和隐藏目录中的很多无关内容
4. rg 的输出更偏向代码搜索场景，文件名、行号、高亮都更直接
5. 在大多数代码仓库里，rg 往往比 grep -R 更快

所以可以把它理解成：

• grep 更通用、更传统
• rg 更像“默认配置已经替你调好的代码搜索工具”

二、安装 rg

不同系统安装方式略有区别，常见命令如下。

1. Debian / Ubuntu

apt update
apt install ripgrep -y

2. CentOS / Rocky / AlmaLinux

yum install ripgrep -y

如果系统源里没有，也可以先启用 EPEL 再安装。

3. Arch Linux

pacman -S ripgrep

4. macOS

brew install ripgrep

安装后先确认版本：

rg --version

三、最常用的 rg 搜索方式

下面直接看几个高频场景。

1. 当前目录递归搜索字符串

比如要在当前项目里找 TODO：

rg "TODO"

对应的 grep 写法通常是：

grep -R "TODO" .

这里第一个差异就很明显：rg 默认就是递归，grep 通常要手动加 -R。

2. 显示行号

rg 默认就会把行号打印出来，大多数时候不用额外加参数：

rg "timeout"

如果你想在 grep 里得到类似效果，一般要这样写：

grep -Rn "timeout" .

3. 按文件类型搜索

只想在 Python 文件里找 def main：

rg -n -g '*.py' 'def main'

grep 也能做，但通常更绕一点：

grep -Rns --include='*.py' 'def main' .

如果你经常按扩展名筛选源码文件，rg -g 会比 grep --include 更顺手。

4. 忽略大小写搜索

rg -i "error"

对应 grep：

grep -Rni "error" .

5. 查看匹配附近上下文

比如想看匹配行前后各 2 行：

rg -C 2 "panic"

对应 grep：

grep -RnC 2 "panic" .

6. 搜索隐藏文件或被忽略的文件

默认情况下，rg 会尊重 .gitignore，这通常是优点，但有时你就是要搜隐藏内容。

rg --hidden --no-ignore "API_KEY"

如果你只想搜索隐藏文件，但仍然保留 ignore 规则：

rg --hidden "API_KEY"

这也是 rg 很实用的一点：默认安静，必要时再显式放开范围。

四、rg 和 grep 直接对比

下面用开发里最常见的几个维度直接看区别。

如果你只想记一条经验，可以记这个：

• 搜源码仓库优先用 rg
• 写兼容性要求高的 shell 脚本，或者处理标准输入时，grep 依然很重要

五、一个更贴近实战的例子

假设你接手一个 Python 项目，想查所有和 requests 超时有关的代码。

用 rg 可以这样写：

rg -n -g '*.py' 'timeout|read_timeout|connect_timeout'

如果你还想把测试目录排除掉：

rg -n -g '*.py' -g '!tests/**' 'timeout|read_timeout|connect_timeout'

同样的事情用 grep 也能做，但会更依赖 find、xargs 或更长的参数组合。

再比如查日志里的 500 错误：

rg -n -C 2 ' 500 |HTTP/1.1" 500' logs/

这种“既要递归、又要上下文、还要控制搜索范围”的场景，就是 rg 最容易体现优势的地方。

六、怎么自己验证 rg 比 grep 更快

不同机器、不同目录，速度不一定完全一样，所以最稳妥的办法还是自己测一次。

例如在一个代码仓库里分别执行：

time grep -R "function" . > /tmp/grep-result.txt
time rg "function" > /tmp/rg-result.txt

观察两点：

1. 总耗时
2. 输出结果是否包含了你真正关心的文件

在很多项目里，rg 不只是快，还因为默认忽略了大量无关目录，所以结果通常更干净。

七、常见问题

1. 提示 rg: command not found

说明系统还没安装 ripgrep，先执行前面的安装命令。

2. 为什么 rg 没搜到我知道存在的字符串

优先检查下面几件事：

1. 文件是不是被 .gitignore 忽略了
2. 目标是不是隐藏文件
3. 目标是不是二进制文件

可以先这样放开限制再试：

rg --hidden --no-ignore "keyword"

3. grep 就不能替代 rg 吗

能替代一部分，但体验不同。

如果你只是临时在一个文件里 grep 一下，或者在管道里筛选标准输出，grep 完全够用；如果你一天里反复在项目目录里搜代码、日志、配置，rg 基本会更高效。

八、总结

grep 没有过时，它依然是 Unix 工具链里非常核心的一环。但如果你的主要场景是“在项目里快速找代码、配置和日志”，rg 基本就是更现代、默认更合理的选择。

实际使用时可以简单一点：

1. 搜整个项目先用 rg
2. 写老脚本或处理标准输入继续用 grep
3. 遇到结果不全，再补 --hidden 或 --no-ignore

这样切换，通常最省时间。