rg进程CPU占满本质是搜索范围失控，需同时配置search.exclude、files.watcherExclude和search.followSymlinks为false，并调高inotify限制，否则rg仍会扫描被exclude路径。
rg 进程 CPU 占满，本质是搜索范围失控
VSCode 默认用 rg（ripgrep）做全局搜索，它本身极快，但一旦被扔进 node_modules、dist、.git/objects 这类目录，就会瞬间拉满单核 CPU —— 不是 rg 有问题，是你没拦住它。
常见错误现象：rg 进程在任务管理器里长期 >90% 占用；搜索框卡在“正在搜索”不动；Ctrl+Shift+F 按下后风扇狂转。
- 别只改
search.exclude：它只影响 UI 层显示结果，rg仍会扫描被 exclude 的路径，除非你同时配对files.watcherExclude和系统级 inotify 限制 -
search.exclude的通配符必须用双星号**，写成*node_modules*或/node_modules/无效 - Linux 用户务必检查
fs.inotify.max_user_watches，低于 524288 时 watcher 会静默失败，触发rg反复重扫
settings.json 必加的三项搜索限流配置
直接编辑工作区或用户级 settings.json，这三行能切掉 80% 的无谓扫描：
{
"search.exclude": {
"**/node_modules/**": true,
"**/dist/**": true,
"**/build/**": true,
"**/*.log": true,
"**/coverage/**": true
},
"files.watcherExclude": {
"**/node_modules/**": true,
"**/dist/**": true,
"**/build/**": true,
"**/.git/objects/**": true
},
"search.followSymlinks": false
}
search.followSymlinks 关键在于：软链接若指向一个巨量文件树（比如 Docker 构建缓存或远程挂载卷），开启它等于主动给 rg 发射制导导弹。
注意：files.watcherExclude 不影响已打开文件的语法高亮，只阻止文件变更监听——关了它，node_modules 就不会因一个 package-lock.json 更新就触发全量重索引。
临时搜索时手动限定目录，比全局配置更准
Ctrl+Shift+F 打开搜索面板后，左上角有个小文件夹图标，点击可指定「仅在此文件夹中搜索」。这个操作绕过所有 exclude 配置，直奔目标目录，适合：
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- 只想搜
src/utils下的函数调用，不碰tests和legacy - 确认某个报错堆栈里的路径是否真实存在，避免被
node_modules里的同名文件干扰 - 大仓库里定位某次提交引入的硬编码字符串，排除构建产物干扰
此时 rg 进程内存通常压在 50MB 以内，响应时间从秒级降到毫秒级。
禁用 GitLens 等扩展的自动搜索联动
GitLens 的 gitlens.hovers.enabled 和 gitlens.codeLens.enabled 默认会为每行代码发起上下文搜索，背后调用的也是 rg。当光标悬停在 import 行时，它可能正偷偷扫整个 node_modules 找引用来源。
实操建议：
- 在设置中搜
gitlens.hovers.enabled，设为false - 搜
gitlens.codeLens.enabled，同样关掉 - 如果真需要 blame，右键菜单里点 “Git: Blame Annotated Line” 是按需触发，不常驻
这类扩展的搜索行为不会出现在 Developer: Open Process Explorer 的 Search 进程里，而是藏在 Extension Host 下，容易被忽略。
真正难处理的从来不是配置项本身，而是那些默认开启、不声不响就把 rg 推向全盘扫描的联动机制——它们往往只在你打开一个新项目、升级插件、或切换分支后才突然爆发。
