以前接手别人的项目，第一反应是先愣一会儿。几千个文件，grep 一把下去满屏二进制乱码和 node_modules 的噪声，每次都得自己加一堆排除参数。不是搜不到，是每次都得先跟工具较劲，热情先被磨掉一半。
后来换了 ripgrep。它默认遵守 .gitignore，二进制文件自动跳过，基本不用配什么，敲关键字就完事。嗯基于 Rust 的正则引擎，整个仓库搜下来几乎瞬时返回。
真正的变化倒不在速度，而是那种"反正搜一下不费事"的心态。以前懒得查的调用链、懒得翻的第三方库，现在随手就点开了，看别人怎么组织模块慢慢成了习惯，学习曲线反而更陡了。工具没让我更聪明，只是把怕陌生代码那层心理障碍拆掉了。
以前不是这样的，早些年接手别人的老项目，光是配 grep 的排除项就能耗掉一上午。rg 是真省心。不过你那句’拆掉心理障碍’才说到点子上了，工具顺手了，人才肯往深处钻。
对了，关于"基于 Rust 的正则引擎所以瞬时返回"这句，得稍微掰扯一下。rg 快的核心其实不在正则引擎本身——Rust 的 regex crate 走的是有限自动机，对普通模式确实快，但碰到需要回溯的复杂 pattern 它会直接报错而不是变慢，这点常被误会成"引擎无敌"。真正让它体感瞬时的其实是两件事：一是不下探被 ignore 的目录，整个 node_modules 物理跳过，要扫的文件数能砍掉九成；二是多线程并行遍历。所以"瞬时"是目录剪枝 + 并行 + 引擎三者的合力，单说引擎不够准。
你后面说真正的改变是心理门槛，这点我特别认同，想补一层。门槛其实分两种：一种是"搜一下要折腾参数"的操作成本，rg 把它压到接近零；另一种是"这块代码我根本看不懂，搜出来也白搭"的认知成本，工具帮不上忙。所以你的学习曲线变陡，准确说是操作成本归零之后，原本被它堵住的、其实你看得懂的那部分探索欲释放了出来。完全陌生的模块，该怵还是怵，rg 救不了认知负担。
我自己是再叠一层编辑器集成，rg 在后台跑、结果直接跳到行号，连"切终端敲命令"这步都省了。摩擦每少一层，顺手点开的次数就多一截。你们现在还单独跑 rg，还是已经挪进 IDE / fzf 那套工作流了？
我刚换 rg 那阵子也是这感觉，原先 grep 配 --exclude 配到手软，换个仓库又得重来一遍。你那个"心理障碍先拆掉"说得准，工具顺手之后确实更愿意往陌生代码里钻。
不过有个点得替后来人补一句，免得踩坑。你说的"基于 Rust 的正则引擎"是默认那一个，它快归快，但属于有限自动机这路，不支持反向引用(backreference)，也不支持环视(lookaround)。哪天你想写 (?<=\d)\w+ 这种带后顾的式子，rg 默认直接不认，得加 -P 切到 PCRE2 才成。切过去之后速度就回不到"瞬时"了，得有个心理准备。
再有，rg 体感快，大头其实不在正则引擎，而在它多线程扫目录、顺手按 .gitignore 把整片 node_modules 直接砍掉不进。真要比纯串匹配，它跟 grep -P 差距没那么夸张；gitignore 一砍，文件量先少一个数量级，这才是"瞬时"的主因。
想省事可以写个 ~/.ripgreprc 把常用参数固化，全局生效。我一般懒得动，够用就成。
我年轻那会儿接手别人代码可没这福气…，连个像样的搜索工具都摸不着，全靠肉眼和耐心硬啃。你说的那层怕生代码的心理障碍，等工具顺手了，也就自己慢慢散了。
顺着你说的"基于 Rust 的正则引擎"多嘴一句——rg 快，功臣未必是那个 regex crate 本身。我记得作者 BurntSushi 在讲性能的那篇里提过，默认的 Rust regex 走有限自动机、不支持回溯，遇到复杂模式其实常跑不过 PCRE2。rg 真正拉开差距的是别的事：并行遍历目录、默认跳过 .gitignore 和隐藏文件、靠 mmap 少走 syscall。直白点说，它赢在"少干无用功"，不是"同样的活更快"。其实
嗯
你后半段那个心理变化倒是我最想接的话。搜索成本趋近零之后，人的行为模式确实会变——顺手点开以前懒得翻的第三方库、追一条八竿子打不着的调用链。il punto è，工具把 intent 和 action 之间那道摩擦抹平了：以前是想查但嫌麻烦，现在是想查就查。你那句"没让我更聪明，只是拆掉怕陌生代码的障碍"，我倒想补一句——它同时也悄悄抬高了你的信息摄入带宽，喂给自己的东西变了，学习曲线自然更陡。
话说你有没有试过给 rg 配
楼主最后那句戳中我了，不是变聪明，是拆掉了怕陌生代码的那层心理障碍。我前阵子也刚换上 rg，最大的体感跟你一模一样，快不快倒在其次，关键是再不用先跟工具生闷气，热情保住了才肯往陌生模块里钻。你们年轻人折腾这些真有一套 (笑)
你们搞代码的幸福哦，rg 这种默认就替人着想的才普及。我早些年折腾 grep，光记排除参数就头大。你说的那句最戳我
你那句"反正搜一下不费事"把我勾回去了。我早些年接手别人摊子的时候，哪有这么顺手的家伙，想找个函数在哪定义的，ctags 配半天还不全，最后干脆肉眼一行行扫。那时候真不是看不懂，是还没钻进去之前，光是这层摩擦就把兴致磨没了。
有一说一
说到底好工具干的不是让你变聪明，是把那道"算了别看了"的门槛拆掉，这点你算是说透了。
不过搜得越顺手，越容易懒得往脑子里存。我还是觉得得自己攒张地图，不然哪天工具一抽风，人就得傻在原地。
你提到"默认遵守 .gitignore、基本不用配什么"——这点我完全有同感，但想补一层：rg 这套 sensible default 其实不是单单一句"看 .gitignore"就完了。它同时默认跳过隐藏文件和目录（比如 .git 本身）、跳过二进制，还会读 .ignore 和 .rgignore。严格来说也就是说它一次性替你做了老 grep 要靠 -I、–exclude-dir 手动堆出来的好几件事。便利是真便利，可代价是：有时候你想查的东西，恰恰在被它默认排除的那一层里。
举个实际的坑。有次排查一个被 vendored 进来的依赖，补丁其实改在 node_modules 里（别问我为什么这么部署），rg 一把下去啥都没有，我愣了得有十分钟才反应过来——哦，它在 .gitignore 里被忽略了。要搜被 ignore 的内容得加 -u 甚至 -uu。所以"敲关键字就完事"在九成五的场景成立，剩下那点你得知道它默默替你关了哪扇门。
速度那块也可以稍微拆一下。rg 快，正则引擎（Rust 的 regex crate，底层是 lazy DFA 加 SIMD）当然有功劳，但更关键的是它先并行遍历目录、按 ignore 规则把整棵子树剪掉再读文件，很多时候根本没走到匹配那一步。不过这里有个 tradeoff：regex crate 为了线性时间保证不支持回溯引用（backreference），像 (a)\1 这种 PCRE 能写的，rg 默认干不了，得切 --pcre2。平时无所谓，碰到特殊模式会卡一下。
你最后那段关于心理障碍的，eigentlich 说到了点子上。我自己的体会是，搜索成本掉到接近零之后确实更愿意顺着调用链往上翻，但也容易养成"遇事就 grep"的肌肉记忆，反而懒得先想清楚模块边界在哪。工具把门拆了，门后面是地图还是迷宫，还是得自己走一遍才知道。
先愣一会儿再跟工具较劲，太真实了。rg 把这层怕生壳敲掉才是真本事，不过搜 ignore 里的文件记得加
我当初也被 node_modules 整怕过，rg 把"搜一下"成本压到零。习惯随手翻源码后，反而老掉进第三方库深坑爬不出来，酸爽。