最近把仓库里的grep全换成rg了，体验是降维打击。
简单说
一句话：在百万行代码里定位字符串，rg基本秒回。我那个repo光vendor就几十万行，以前grep -r要等好几秒，还刷一堆node_modules的垃圾。现在rg默认跳过.gitignore和二进制文件，结果干净得不像话，一眼就能看到想要的，这点对我这种受不了噪音的人太友好了。

速度快不是玄学。它是Rust写的，多核并行扫描，遇到纯字面量会走更优的匹配路径，比GNU grep快一个数量级很正常。你不用懂这些也照样爽，但知道底层为啥快，用着更踏实。

彩色高亮做得舒服，匹配行把关键字直接染出来，正则跟PCRE基本对齐，复杂pattern也能写。我编辑器里拿rg做模糊查找的后端，即搜即跳，光标直接落那一行。git grep不是不能用，但rg不绑仓库，临时扒个目录也方便。老grep可以安心退休了。

一个修正：rg 默认正则引擎不是 PCRE，是 Rust 的 regex。快，但没 lookaround、没 backreference，写 (?<=x) 这种零宽断言直接报错。要 PCRE 得显式加 -P / --pcre2。
其实
我图省事，export 了 RIPGREP_CONFIG_PATH 指向 ~/.ripgreprc，里面常开

你那句"正则跟PCRE基本对齐"，我得较个真。rg默认走的是Rust的regex crate，和PCRE是两套实现：前者是有限自动机引擎，刻意不支持反向引用(backreference)和环视断言(look-around)，换来的是线性时间复杂度和不会灾难性回溯。所以像 (?<=foo)bar 这种前后向断言，默认引擎直接报错。真要写PCRE风格的高级正则，得显式加 --pcre2 且用带PCRE2支持编译的版本。所以"基本对齐"不够严谨，确切说是常见语法覆盖得不错，但高级特性得切PCRE2才全。日常搜代码基本够用，这点你没说错。

读着读着想起夜里打着手电走在野地里，光只照你想看的那一截路，四周的草虫都不吵了。rg 这份安静，比快更难得。

前两年我把常用搜索也切到rg，再回去用grep就总觉得哪儿别扭，像习惯了自动挡又去开手动。

不过有一回倒被老grep救了一把。那天远程登一台特别精简的容器，里面压根没装rg，二进制都给裁掉了。我下意识敲了rg，报错才反应过来这地方只有grep能靠。从那以后我的态度就变了：好东西尽管用，可脑子里得留着老法子的位置，指不定哪天就落到没新工具伺候的环境里。坦白讲

新刀快，老刀也别急着扔。

楼主那句"受不了噪音"，简直替我说了出来。rg最勾人的地方，未必是快，而是它默认就替你把不想要的东西拦在门外了——.gitignore、二进制、那些node_modules深处永远不会去翻的角落。这种"先替你做减法"的脾气，比单纯的速度更让人受用。

我倒觉得，这背后是一种克制的设计哲学。老grep像个老实巴交的伙计，你问什么它都翻给你看，连带一堆废纸；rg则像个懂你的管家，先替你判断哪些不值当。速度之外，这份"替你拒绝"的体贴，才是它让人离不开的真正理由。

楼主提到"知道底层为啥快，用着更踏实"，这点我极认同。工具一旦成了黑箱，用久了会发虚；rg把Rust、多核并行、字面量优化这些底牌摊开，反而让人安心。用着踏实，这四个字比快多少个数量级都金贵。

说"老grep安心退休"，我想补一句：有些极窄的场合它还在——连rust运行时都凑不齐的救援环境，或者很老很旧的机器上，grep -r仍是兜底的那根稻草。我偶尔还会在终端里敲它，倒不全是怀旧，是知道有根更朴素的绳攥在手里，心里稳当些。工具这东西，未必谁替了谁，更多是夜里多了一盏灯，亮着，就好。

读到「干净得不像话」那句，忽然觉得，能不被噪音淹没的眼睛真难得。就像夜里熄了灯，才看见窗外那点月光。

借你帖子里那句"受不了噪音"，我之前也是这样。grep一跑满屏乱七八糟，换上rg后总算清净了~

rg 默认那个正则引擎其实不吃 lookahead/lookbehind 和反向引用，这点挺容易踩坑。你贴里说「正则跟 PCRE 基本对齐」，严格讲得加 -P 切到 PCRE2 后端才行；不加 -P 时它跑的是 Rust 自己的 regex crate，为了线性时间复杂度主动放弃了回溯类特性。我写 (?<=\d)\w+ 这种零宽断言时白等了半天才反应过来要补 -P。

速度上的「降维打击」，大头其实不全是 Rust 多核，而是它默认就不进 .gitignore 和隐藏目录。你那个 vendor 几十万行，grep -r 慢主要是把 node_modules 和 .git 也扫进去了。给 GNU grep 加上 --exclude-dir=.git --exclude-dir=node_modules，差距会明显缩小，不再是一个数量级。所以 rg 是赢在默认值合理，不光赢在快。

老 grep 还不能完全退。rg 的 -r/–replace 只往 stdout 打替换结果、不回写文件，批量改字段还是得 sed -i 或 perl -i 收尾。纯管道里逐行过滤的场景，grep 也照样顺手。
简单说
rg 配 fd 用着最爽：文件名归 fd，内容归 rg，职责切得干净，fzf 的 --preview 直接挂上就能即搜即预览。你编辑器里那套即搜即跳要还没接 fd，可以试一把。

你那套后端是 neovim 的 telescope 还是 vscode 的？

话说你夸 rg 默认跳过 node_modules 那段，我倒想从反面补一句：恰恰就是那种"受不了噪音"的人，最容易被这个默认值坑。上个月我线上某个依赖莫名抛错，stack trace 指向一个 vendor 里的包，我第一反应 rg 一把梭，结果毛都没有——因为它乖乖替我把 node_modules/vendor 跳了。最后老老实实 rg -u --hidden 才把那行鬼东西捞出来。所以说"干净得不像话"是爽，但真要刨根问底的时候，你得先跟自己脑子里的默认行为打一架。

速度这块你说得在理，不过有个小提醒：那个"秒回"很大程度是暖缓存的功劳。行吧头一回在冷盘上扫百万行，照样能听见硬盘哼哧哼哧。rg 牛的是把该快的地方做到了极致，不是把磁盘 I/O 变没了。真到了几十 GB 的单体巨仓，瓶颈早跑到别处去了。
呵呵
至于"老 grep 安心退休"——我保留意见。你随便拎个精简容器、busybox 环境，或者帮同事看台没装 rust 的老机器，grep -r 还是兜底的那个。便携性这种东西，平时想不起来，真到荒郊野外才显出价值。哈哈哈不过当主力搜索，rg 确实降维打击，这点我不抬杠。

顺带一个彩蛋：要是你哪天想搜"结构"而不是"字符串"——比如找出所有调用了某函数但写法五花八门的地方——rg 的正则就开始别扭了，那种活儿得上 ast-grep 这类吃 AST 的工具。两者不是一个赛道。

你编辑器接 rg 做即搜即跳那段我完全共鸣，我现在 fzf 后端也是它，回不去了属于是。

有个地方想跟你较较真。你说 rg 的正则“跟 PCRE 基本对齐”，这句话在默认配置下其实站不住。

rg 默认走的是 Rust 的 regex crate，不是 PCRE。它的引擎是 DFA/NFA 混合有限自动机，换来的是线性时间、不会回溯爆炸，代价是不支持回溯引用（backreference）和大部分环视。比如 (\w+)\s+\1 这种抓重复词的 pattern，默认引擎直接报错，得上 --pcre2 才跑得动——而 --pcre2 依赖编译时带 PCRE2 支持（官方预编译包现在默认带，但自己 cargo install 出来的不一定）。所以更准确的说法是“常用语法对齐”，碰到高级特性就分叉了。

“比 GNU grep 快一个数量级”也值得拆。很大一块速度差是默认过滤贡献的：rg 跳过 .gitignore、隐藏目录和二进制，而 GNU grep -r 是全量扫。你给 grep 也加上 --exclude 把 node_modules、.git 挡掉，差距会落到两三倍，谈不上十倍。rg 真正的硬功夫是多核并行加大文件 mmap 扫描，这块在百万行以上的仓库才明显拉开身位。

git grep 也不至于安心退休。它只搜已跟踪文件，在满是临时改动的 working tree 里排干扰比 rg 还干净，裸 CI 环境往往也没装 rg。三者更像互补，按场景挑着用最实在。

我去年也叛变到rg了，当时就是受不了grep