上一篇预告过，这次实测 BurntSushi/ripgrep（命令名 rg）。网上关于它的说法基本是一句话：比 grep 快很多。到底快多少、快在哪、哪些场景是"假快"，我在本机拿同一批文件、同一个关键词，跟 GNU grep 正面比了一轮，顺手把几个容易让人以为"rg 漏搜了"的坑也复现了一遍。
本机实测 + AI 辅助整理。测量时间：2026-11-02（Asia/Shanghai）。每组命令先预热 1 次，再取 5 次（/usr 那组取 3 次）的中位数，文件都在页缓存里，属于"热缓存"成绩。
本机环境
text
OS: Debian 13 x86_64，8 核
rg: ripgrep 14.1.1
grep: GNU grep 3.11安装：Debian/Ubuntu 直接 apt install ripgrep，macOS brew install ripgrep，Windows winget install BurntSushi.ripgrep.MSVC。我这台机器上已经有了，rg --version 确认即可。
测试素材
为了贴近"在项目里搜代码"的真实场景，我拼了一个 164M 的目录：
src/：Python 标准库 + 一堆 dist-packages，98M、4204 个文件node_modules/：一个前端小项目的依赖，66M、1081 个文件- 根目录
git init，.gitignore里写了node_modules/
另外再拿整个 /usr（3.6G、51314 个文件）做大目录测试。
实测 1：同样全扫，rg 快 5～9 倍
先让两边搜的范围完全一样（rg -uu 表示不看 ignore 规则、也搜隐藏文件），对比结果行数一致，确认没有漏搜：
| 场景 | grep 中位数 | rg -uu 中位数 | 输出行数 | 倍数 |
|---|---|---|---|---|
普通关键词 function |
0.166 s | 0.034 s | 19599 = 19599 | ≈4.9× |
忽略大小写 -i |
0.227 s | 0.039 s | 21532 = 21532 | ≈5.8× |
正则 [A-Z][a-z]+Error\( |
0.320 s | 0.036 s | 7063 = 7063 | ≈8.9× |
固定字符串 -F 'def __init__' |
0.238 s | 0.031 s | 2208 = 2208 | ≈7.7× |
规律很明显：模式越复杂，差距越大 。grep 遇到正则和 -i 会明显变慢，rg 基本稳定在 30 多毫秒。
那是不是只因为 rg 多线程？我用 -j1 把它压成单线程再跑一次：
text
rg -j1 -n -uu 'function' . 中位数 0.047 s单线程仍然比 grep 的 0.166 s 快 3.5 倍左右。多线程是加分项，但不是全部原因。
实测 2：默认模式下，rg 自动跳过 node_modules
不加任何参数直接 rg -n 'function' .：
text
rg 默认 0.024 s 5598 行
grep -rn（不排除） 0.166 s 19599 行
grep -rn --exclude-dir=node_modules --exclude-dir=.git 0.128 s 5598 行rg 读了 .gitignore，node_modules 里那 1.4 万行"噪音"直接不出现，结果和手写两个 --exclude-dir 的 grep 一模一样，但快了约 5 倍、命令也短得多。日常在项目里搜代码，这才是 rg 最大的好处：不用每次都记得排除依赖目录。
实测 3：/usr 3.6G，62 倍是怎么来的
整个 /usr 搜 Copyright (C) 2019：
| 命令 | 中位数 | 结果行数 |
|---|---|---|
grep -rn |
7.431 s | 65 |
rg -n -uu |
0.120 s | 65 |
rg -j1 -n -uu（单线程） |
0.441 s | 65 |
7.4 秒对 0.12 秒，算下来 62 倍，截图发出去很好看。但我觉得这个数字有水分 ：/usr 里有大量二进制文件（.so、可执行文件），GNU grep 默认会把二进制文件从头读到尾，只为告诉你一句 binary file matches；rg 一发现文件里有 NUL 字节，就判断是二进制并停止读这个文件。
把 grep 也改成跳过二进制（-I），再让 rg 反过来强制完整读二进制（-uuu）：
| 命令 | 中位数 | 结果行数 |
|---|---|---|
grep -rnI（跳过二进制） |
0.568 s | 65 |
rg -n -uu |
0.120 s | 65 |
rg -n -uuu（二进制也全读） |
0.786 s | 65 |
公平对比下来，rg 比 grep -rnI 快大约 4.7 倍 ，不是 62 倍。反过来，让 rg 去啃二进制，它也会比 grep -rnI 慢。结论：大目录里 grep 慢，一大半是在白读二进制；给 grep 加个 -I，差距立刻从几十倍缩到几倍。
踩坑清单（都在本机复现过）
坑 1：.env 搜不到------rg 默认不搜隐藏文件
text
$ rg -n token a
a/main.py:1:token = 1
a/build/out.js:1:token build
$ rg -n --hidden token a
a/main.py:1:token = 1
a/.env:1:API_KEY=secret_token
a/build/out.js:1:token build想排查"配置里有没有写死密钥"时，这个默认行为最坑：rg 安静地跳过了 .env，你还以为没有。要搜隐藏文件加 --hidden，连 ignore 规则一起关掉用 -uu。
坑 2：.gitignore 有时生效、有时不生效
同样的目录、同样的 .gitignore（里面写着 build/）：
text
目录 a（没有 git init）: rg 仍然搜出了 a/build/out.js
目录 b（git init 过）: build/ 被跳过，只剩 main.py
目录 a 加 --no-require-git: build/ 被跳过rg 14 默认只在 git 仓库里 才认 .gitignore。刚解压的源码包、没 init 的文件夹，.gitignore 等于没写。想让它照样生效，加 --no-require-git，或者改用 rg 自己的 .ignore / .rgignore 文件。
坑 3：从 grep 抄来的模式直接报错
text
$ rg -n 'main(' a
rg: regex parse error:
(?:main()GNU grep 默认是基础正则，( 是普通字符；rg 的语法接近扩展正则，( 是分组。搜带括号的代码时，要么写成 'main\('，要么直接 rg -F 'main(' 当固定字符串搜。
坑 4：前瞻断言不支持，要加 -P
text
$ rg -n 'token(?= =)' a
rg: regex parse error ...
$ rg -nP 'token(?= =)' a
a/main.py:1:token = 1rg 默认的正则引擎为了保证线性时间，不支持前瞻/后顾和反向引用。需要时加 -P 切到 PCRE2（我这台的发行版包带了 PCRE2，自己编译的版本可能没有）。
坑 5：别拿"62 倍"去说服同事
见实测 3。二进制文件多的目录，差距主要来自 grep 读二进制；先给 grep 加 -I 再比，才是公平的。
顺手好用的几个参数
bash
rg -t py 'def main' # 只搜 Python 文件（本机 rg --type-list 有 206 种类型）
rg -l 'TODO' # 只列文件名
rg -C 2 'panic' # 前后各 2 行上下文
rg --hidden -g '!.git' 'API_KEY' # 搜隐藏文件但排除 .git小结
| 项 | 本机结果 |
|---|---|
| 同范围全扫（164M） | 快 4.9～8.9 倍，正则和 -i 差距最大 |
| 单线程 | 仍快约 3.5 倍 |
| 默认模式 | 自动跳过 .gitignore 里的目录，结果等同手写 --exclude-dir |
| 3.6G /usr | 表面 62 倍；grep 加 -I 后实际约 4.7 倍 |
| 坑 | 隐藏文件、非 git 目录的 .gitignore、括号转义、前瞻要 -P |
一句话：在项目里搜代码，rg 又快又省心；但它的"默认跳过"是双刃剑，查密钥、查配置时记得加 --hidden 或 -uu。
完整的测量脚本和进阶踩坑表以后会整理上架 Gumroad，先关注专栏「GitHub实测笔记」。
上一篇：jc 本机实测（把 ps/df/ip/ls 输出变成 JSON）。
下一篇预告：sharkdp/fd------和 find 比找文件的速度和默认行为。有问题评论区见，看到都会回。