必须同时配置search.exclude和files.watcherexclude，前者控制搜索阶段跳过内容读取，后者阻止监听阶段注册路径；仅配其一仍会导致卡顿，且路径必须为"/node_modules/"格式，修改后需重新打开工作区。
search.exclude 和 files.watcherExclude 必须同时配
只配 search.exclude，搜索时依然卡顿——它只跳过读取内容，不阻止文件监听器注册路径。只配 files.watcherExclude，搜索面板打开仍慢，因为初始索引阶段已漏掉排除逻辑。二者是前后两道闸门：search.exclude 控制“搜什么”，files.watcherExclude 控制“监听什么”。
常见错误写法："node_modules"、"**/node_modules" —— 正确必须是 "**/node_modules/**"（结尾 /** 表示递归排除整个子树）。同理，.git 要写成 "**/.git/**"，否则 Git 状态扫描照常暴走。
- 修改后必须关闭并重新打开工作区，不是仅重启窗口
-
files.watcherExclude支持文件后缀，比如"**/*.log"，单个 2GB 日志文件足以让 watcher 队列阻塞数秒 - 如果项目用了
.gitignore，建议把里面所有非空行路径转成files.watcherExclude条目，避免 GitLens、ESLint 等插件重复扫描同一堆垃圾
search.followSymlinks 设为 false 很关键
在 monorepo 或用 yarn link/npm link 的项目里，符号链接常指向外部 node_modules 或 packages 目录。默认 search.followSymlinks: true 会让 VS Code 顺着链接一路扫进去，瞬间多出几千个文件。
设为 false 后，搜索只停在链接文件本身，不穿透。这个开关不影响代码跳转（Go to Definition），只影响 Ctrl+Shift+F 和 Ctrl+P。如果你依赖符号链接开发，可临时启用，但长期开着等于主动喂 CPU 垃圾。
别信“全局配置就够了”，项目级 .vscode/settings.json 才可靠
全局设置容易被覆盖，且无法随项目共享。团队协作时，不同人本地环境差异大，只有项目根目录下的 .vscode/settings.json 能保证所有人用同一套排除规则。
推荐基础模板：
{
"search.exclude": {
"**/node_modules/**": true,
"**/dist/**": true,
"**/build/**": true,
"**/.git/**": true,
"**/coverage/**": true,
"**/*.log": true,
"**/*.zip": true,
"**/*.pdf": true
},
"files.watcherExclude": {
"**/node_modules/**": true,
"**/dist/**": true,
"**/build/**": true,
"**/.git/**": true,
"**/.next/**": true,
"**/out/**": true,
"**/target/**": true,
"**/*.log": true
},
"search.followSymlinks": false,
"search.useIgnoreFiles": true
}
search.useIgnoreFiles: true 会自动遵循 .gitignore 规则，但注意：它只对搜索生效，不影响文件树显示或语言服务。
临时大文件？手动限域比等配置更稳
即使配置全对，临时生成的 report.json、未被 .gitignore 覆盖的构建产物、或某次本地导出的几百 MB 日志，仍可能拖慢搜索。这时最靠谱的方式是：在搜索框右上角点“…” → “Find in Files” → 在 files to include 栏手动填 src/**, lib/**, *.ts 这类精准路径。
这种手动限域绕过了所有排除配置，直接从源头缩小扫描集，实测在 5 万+ 文件项目中能把搜索耗时从 4s+ 压到 0.6s 内。
真正难处理的不是配置本身，而是那些没进 .gitignore、又没被 watcher 排除的“幽灵文件”——它们往往在你最急着找 bug 的时候突然冒出来卡住整个编辑器。
