VSCode搜索卡顿主因是文件监视器被大目录拖垮，须协同配置files.watcherExclude（如"/node_modules/"）和search.exclude，且大文件应启用只读模式。
VSCode 搜索卡顿，90% 不是搜索本身慢，而是它在拼命扫描你根本不想搜的大文件和目录——禁用插件只是表象，真正要动的是 files.watcherExclude 和 search.exclude 的协同配置。
为什么关了 GitLens/Prettier 还搜得慢？
这类插件不是“扫描慢”，而是它们依赖的底层机制——文件监视器（watcher）早已被 node_modules、.git/objects、app.log 等路径拖垮。一旦 inotify 句柄耗尽，VSCode 就退化为轮询模式，CPU 持续 30%+，搜索延迟从 2s 起跳。
-
GitLens默认监听所有文件变更来渲染 blame 行，遇到.git/objects/**里数万个小对象就卡死主线程 -
Prettier不直接导致搜索慢，但它激活时会拉起语言服务，而语言服务又依赖 watcher 提供的文件列表——坏链一环扣一环 - 禁用插件只能停掉上层逻辑，但 watcher 已注册的路径不会自动清理，必须重载窗口甚至重启工作区
必须写死的 files.watcherExclude 条目
这个配置不是“建议加”，是系统级保命项。漏掉任意一条，都可能让 watcher 在几秒内崩溃。
-
"**/node_modules/**"：结尾/**不可省略，否则只排除顶层文件夹，不递归子目录（比如packages/foo/node_modules仍会被扫） -
"**/.git/objects/**"：Git 对象库是高频坑点，.git根目录排除不够，必须深入到objects层 -
"**/*.log"：单个 500MB 的日志文件就能阻塞整个 watcher 队列，通配符必须带* -
"**/target/**"、"**/.next/**"、"**/out/**"：这些构建产物目录结构深、文件多，且内容完全无关搜索
search.exclude 和 files.watcherExclude 必须配齐
二者作用阶段不同，缺一不可：
-
search.exclude生效于你按下Ctrl+Shift+F后，只跳过匹配路径的文件内容读取 -
files.watcherExclude生效于 VSCode 启动或打开工作区时，直接阻止操作系统注册监听路径——这才是真正“不读”的源头 - 常见错误：只配
search.exclude却没配files.watcherExclude，结果搜索界面不显示venv/下的文件，但 CPU 依然狂转，因为 watcher 还在疯狂响应.pyc变更 - 路径写法差异：
search.exclude中"**/venv"和"**/venv/**"效果一致；但files.watcherExclude必须用"**/venv/**"才能递归生效
大文件只读模式才是终极方案
当你要查的是单个超大日志或 dump 文件时，别指望搜索优化——直接绕过整套机制。
- 关闭所有标签页，清空当前工作区
- 按
Cmd+Shift+P（macOS）或Ctrl+Shift+P（Win/Linux），输入并执行File: Open Large File Optimized - 选中文件后，务必确认左下角状态栏显示
Large file mode (read-only)；若显示Log或Plain Text，说明失败，重试 - 进入后立刻点击右下角语言模式 → 手动再选一次
Plain Text，防止插件靠languageId绑定复活
这一步跳过了 tsserver、eslint-language-server、所有语言服务加载，连语法高亮都舍弃了——但换来了毫秒级打开和滚动。真正的“快”，有时就是主动放弃功能。
