前阵子查一个老项目的bug，在好几个G的代码仓里翻一个函数调用，grep先是报我的正则语法不对，好不容易改对了又慢得我泡杯茶回来还在转圈。后来被同事按头安利了ripgrep，就是那个rg，用了一把就回不去了。

它底层是Rust写的，搜整仓基本sub-second，多线程扫得飞快，不用再盯着进度条发呆。最省心的是开箱即用：默认就认.gitignore，自动跳过隐藏文件和二进制，我啥都不用配，敲rg "pattern"就能干活。正则语法跟grep基本兼容，老肌肉记忆完全不用改。

现在我的工作流里rg跟fzf、编辑器已经绑死了，搜代码跳定义一条龙。唯一的副作用，大概就是少了个等搜索结果的摸鱼借口 (´・ω・`)

默认认gitignore真省心，我以前grep老把node_modules翻出来干等半天

想顺着你那句"正则语法跟grep基本兼容，老肌肉记忆完全不用改"补充一点。对常用子集确实成立，但rg默认引擎的边界值得说清楚：它底层是Rust的regex crate，基于有限自动机，刻意不支持回溯引用（backreference）和大部分PCRE零宽断言。如果你的老习惯里带着 grep -P 'foo(?!bar)' 这种look-around，或者 (a)\1 这种反向引用，rg默认会直接不匹配或报错，得显式加 -P 切到PCRE2后端才认。所以严格讲不是"完全不用改"，是常用那部分不用改。嗯

另一个容易在某天咬人的点，恰好是你夸的"开箱即认.gitignore"。省心有反面：排查时有些问题偏偏出在 .gitignore 里的生成文件、构建产物上，rg会一声不响地把它们跳过，你对着"No match"发愣半天。这时候 rg -u 或 --hidden --no-ignore 才是钥匙。省心和漏搜是一体两面，得心里有数。

你那个"sub-second"的结论，具体在什么规模的仓、什么硬件上量的？我自己的感觉是冷热缓存差很多，热缓存确实飞起，冷启动扫机械盘上的大仓时，目录遍历的I/O开销还是逃不掉，这时候跟 grep -P 的差距会收窄不少。

至于标题"卸了grep"——本机卸着玩随意，但grep在POSIX里、在每台裸机和CI容器里都默认在场，一堆脚本也假定它存在。远程上去排查，最后摸的往往还是它。rg是你工作流的加速器，grep是那个"永远在"的兜底。

你们rg+fzf+编辑器一条龙，fzf那层你是走

rg 跳过隐藏文件和二进制这点很省心，不过有回我排一个 .env 的错，rg 愣是搜不到，半天才想起是被默认忽略了。要搜 dotfiles 记得带 --hidden，或者 -u 直接关掉 ignore 规则。

你那套 rg + fzf 我也在用，跳定义是真顺手。

rg的正则是Rust regex那套，不支持反向引用和look

rg 那句"正则跟 grep 基本兼容"我得补一刀。默认它跑的是 Rust 的 regex 引擎，为了保线性时间复杂度，主动放弃了对反向引用（\1）和前瞻/后顾这类 PCRE 特性的支持。你搜函数调用这种纯字面或简单通配当然没感觉，可一旦把 grep 里常用的 backreference 搬过来，默认模式直接报 unsupported。要真正兼容 PCRE 得显式加

我也在用rg，不过有一处得掰扯一下：你说正则跟grep基本兼容，这话在常见用法上成立，但rg默认走的是Rust的regex引擎（RE2那一路），不支持反向引用和零宽断言，而grep -P是PCRE。碰到要回溯匹配的复杂正则，老肌肉记忆会翻车。我前阵子想从日志里抓带捕获分组的pattern，rg直接报不支持，最后退回了grep

被剥夺摸鱼借口那段看得我笑眯眯的。我同事也总安利这类工具，不过慢一点偶尔发呆，也挺好呢~

摸鱼借口那段把我逗乐了，我以前等grep也是一杯茶的时间。rg这东西确实香…，不过我刚用时老忘它默认不吃.gitignore里的文件，找不着东西还得补个