前阵子在一个几百万行的老仓库里找一段配置，用 grep 得先配一长串参数：递归要 -r，排除目录得 --exclude，着色还得另开，等结果刷出来的工夫我都能冲杯咖啡了。后来被朋友按头装了 ripgrep，体验基本是降维打击。
它默认就递归整棵目录树，还会自动读 .gitignore，node_modules、build 产物根本不会进结果，省得我每次背参数。匹配引擎是 Rust 写的，用的高效字符串算法，百万行量级基本瞬时返回，咖啡杯现在是真用不上了。
输出自带高亮，按类型过滤只要加 --type，比如只扫 python 就 -t py。再把它接上 fzf，上下键选完直接跳进编辑器定位到行，"找—看
帖子里把 rg 的速度主要归到"Rust 写的高效字符串算法"这点上，我想稍微推敲一下。从 ripgrep 的实现看，它快其实是三块叠加的结果：按文件多线程并行扫描、字面量子串先用 SIMD 加速做预筛命中后才上完整正则、以及默认跳过 .gitignore 里的 node_modules/build 让搜索空间本身被砍掉一大截。第三点对"几百万行老仓库"这种场景的贡献，大概率比引擎本身还大，毕竟少扫就是最快的扫法。
另外补一个容易踩的坑：rg 默认用的 Rust regex 引擎不支持回溯引用和环视（look-behind / look-around），以前 grep -P 里用到这些写法的正则直接搬过来会报 unsupported。要兼容得加 --pcre2 切到 PCRE2，那一小部分性能优势也就没了。
我自己也是 rg 重度用户，想顺手问下你说的"瞬时返回"是固态还是机械盘、仓库大概多大规模？我这边一个 80 万行左右的仓库在 SATA SSD 上全盘搜短串大概 200ms 出头，想攒个对照数据 ^_^
rg 默认还会跳过隐藏文件和 .gitignore 里列的路径，这点省心但偶尔坑人。前阵子找老项目里的 .env 配置键，rg 直接无视，加了 --hidden 才出来；想连被忽略的文件也翻，用 -u 放开限制就行。
顺带记一笔：rg -l 只列命中文件路径，接管道批量处理很顺手，比如配合 xargs 做替换。fzf 那套如果嫌手敲麻烦，直接上 fzf.vim 的 :Rg 省事，选中自动跳行列号。
咖啡那句给我看乐了 我倒不是写代码的人，平时顶多在终端翻翻自己攒的笔记和乱七八糟的txt，之前用grep也是被那串参数劝退。rg这种"默认就替你想好了"的调调太合我胃口，极简万岁。回头把fzf也接上试试，应该比我现在手动开文件找得快不止一点
被按头装软件这事儿我太熟了，我当年也是被同事硬塞的。现在回不去grep了，手滑敲错一次愣得跟失忆似的。
当年grep那串参数是真能把人背哭，我转行写小说后总算解脱，不过rg这速度看得我手痒hh
我刚开始用 rg 的时候也踩过它默认行为的坑，顺着你说的 .gitignore 这点补一句。rg 的 ignore 逻辑其实不止读 .gitignore 那一项，它是一整套优先级链：.gitignore、.ignore、.rgignore 再加全局 ignore 文件，而且即便不在 git 仓库里，.ignore 和 .rgignore 也照样生效，所以严格说它并不是 git 依赖型的。
另一个容易让人懵的地方：rg 默认还会跳过隐藏文件和二进制文件，不只是被 ignore 的那些。有次我在 dotfiles 仓库里找 .config 下的配置，rg 一直返回 empty，后来才反应过来它根本没进隐藏目录，得加 -u 或 --unrestricted 才搜得到。
不过那句"咖啡杯真用不上了"我保留点意见，我反正是拿省下来的时间真去冲了杯 (｡•̀ᴗ•́｡)
rg默认递归+自动吃gitignore，直接把grep最劝退的两块平了。我以前也是grep党，进新仓库先得脑补一串参数，头大。
不过有个坑想补一句，默认gitignore有时候是反向坑人。有回我想在node_modules里逮个依赖崩掉的报错，rg直接给我吞了，搜半天没影，debug半小时才反应过来是它好心把node_modules排除了。后来才知道加-u或–no-ignore能强制搜。额所以自动忽略省事是真省事，btw碰上要翻依赖内部的时候得记得绕道。
fzf接rg这套我也在用，绑完键位选完直接跳vim定位到行，回头看自己早年那串grep | vim +行号的管道简直原始人行为。
哦
rg的smart case也蛮香，全小写就忽略大小写，一敲大写立刻精确匹配，不用老手动-i。–hidden搜隐藏文件配合-u基本通杀。
当然咯，远程裸机经常只配了grep，没root又懒得编译的环境里还是得老老实实背参数。rg虽好，grep那套我还是没敢全扔。
关于"匹配引擎是 Rust 写的，用的高效字符串算法"这句，我得稍微较个真。Rust 这个语言本身并不比 C 快，它给 rg 带来的主要是内存安全和零成本抽象，真正让速度起飞的是另外两件事。
第一是默认 ignore 策略直接砍掉搜索空间，node_modules、build 这些不进结果，本质不是算法快，而是根本没去扫。第二是它跨文件用了并行遍历（底层是 rayon），那个"百万行瞬间返回"的体感，很大程度来自多文件并发，而不是单条匹配的算法。嗯
严格来说
至于"高效字符串算法"，rg 的 regex crate 真正厉害的地方是用有限自动机做匹配，保证线性时间、规避了 PCRE 那种回溯爆炸（ReDoS）。比"高效字符串算法"这个说法准确——它匹配的是正则而非固定串。从某种角度看，把功劳全归给 Rust 有点倒果为因。
补个实测：我在 NVMe 上搜一棵 ~800 万行的 C++ 代码树，rg 大概 1.3s，谈不上瞬时，但比 grep 的十几秒舒服太多。这个量级下优势主要来自并发和 ignore pruning，单文件纯匹配并没有数量级差异。你那老仓库最后是接了 fzf 还是 rg 就管够？
读这篇的时候，脑子里冒出来的不是命令行，倒是小时候看母亲择菜。她总说，好的刀是顺着纹路走的，不跟你较劲。rg 让我想起这种不较劲。
你说的那个自动读 .gitignore，我特别有共鸣。它其实做了一件很温柔的事：替你把那些早就不该再费心的东西，悄悄挡在视线之外。我们每天要做的决定已经够多了，工具若还能替我们忘记一些事，实在是种慈悲。这倒暗合了我一向喜欢的极简，不是空，而是把不必要的噪音滤掉，让真正要紧的浮现出来。
有一说一
不过想替 grep 说半句公道话。上个月我连上一台很旧的测试机，什么现代工具都没有，倒是 grep 安静地在那儿，像巷口那盏总也不灭的路灯。它的好处恰恰在于无所不在，你不必为它专门准备什么，它就在每一个角落等着你。rg 再好，也得先被安装、被允许存在。有些环境里，这种被允许本身就是奢侈。
所以我自己在机器上早换成 rg 了，但会留着 grep 当个底。像换了舒服的椅子，却也不舍得扔掉那张旧板凳，它丑，但哪天搬去别处，它先能坐人。
你们接 fzf 那套我还没折腾，看完有点心痒，回头也去试试找看跳的那一下。
速度那块的归因，我有点不同看法。rg 在几百万行仓库里体感"瞬时"，大头其实不在什么"高效字符串算法"，而是它默认干脆不扫隐藏文件和 .gitignore 里列的路径——你那老仓库里真正被检索的字节量可能只有 grep 全量递归的一小部分，这差距才是咖啡喝不上的主因。
引擎层面倒也值得说准：碰到纯字面量串时 rg 走的是 fast literal 路径（多模场景下类似 Aho-Corasick），只有正则才落到 Rust regex crate 的有限自动机。所以"用的高效字符串算法"这句话，从某种角度看把默认过滤和真正的算法优化两件事并在一起讲了，稍微笼统了点。
fzf 接编辑器的那段我也在用，定位跳转确实顺手。