search.exclude配了仍卡顿，关键在于未同步配置files.watcherexclude：前者仅在搜索时跳过读取，后者才在启动时阻止监听注册；二者必须同时设置“/node_modules/”等规范路径并重启工作区。
为什么 search.exclude 配了还是卡？关键在 files.watcherExclude
VSCode 搜索卡顿，90% 不是搜索慢，是它在你启动时就疯狂监听不该监听的目录。只配 search.exclude 顶多让结果不显示 node_modules 里的内容，但编辑器早已把几万个文件注册进文件监视器（fs.watch），CPU 占用持续 20%+，搜索前就得等 I/O 缓冲清空。
真正阻止“读”和“监听”的，是 files.watcherExclude。它生效于工作区加载阶段，直接跳过路径注册，比 search.exclude 早一个层级。
-
search.exclude：搜索时跳过匹配路径的文件内容读取（后置过滤） -
files.watcherExclude：启动时就不让系统监听这些路径（前置拦截） - 二者必须同时配置，缺一不可；单独配任一个，都可能卡顿
哪些路径必须加进 files.watcherExclude？
除了显而易见的 node_modules 和 .git，真实项目里还有几个高频“ watcher 杀手”，容易被忽略：
-
"**/node_modules/**"：结尾的/**不可省略，否则嵌套的packages/*/node_modules仍会被扫 -
"**/.git/**"：Git 状态扫描本身开销大，尤其历史超 5 年的仓库 -
"**/target/**"：Rust/Java 构建产物，常含大量 class/jar 文件 -
"**/.next/**"：Next.js 缓存目录，JSON 和 JS 文件密集 -
"**/out/**"：TypeScriptoutDir输出，常被漏掉 -
"**/*.log"：单个 2GB 的app.log就能阻塞整个 watcher 队列
建议直接把项目 .gitignore 里所有非空行转成 files.watcherExclude 条目——不是图省事，是避免 Git 插件和搜索插件各自重复扫描同一堆垃圾。
search.followSymlinks = false 是什么场景下必须关？
在 monorepo 或用了 yarn link/npm link 的项目里，符号链接常指向外部 node_modules 或 packages 目录。默认 search.followSymlinks: true 会让 VSCode 顺着链接一路穿透进去，瞬间多出几千个文件要读。
- 设为
false后，搜索只停在链接文件本身，不递归展开目标路径 - 这个开关不影响代码跳转（Go to Definition），只影响全局搜索（
Ctrl+Shift+F）和快速打开（Ctrl+P） - 若你依赖符号链接做开发，可临时启用，但长期开着极易引发卡顿——截至 2026 年 8 月，VSCode 官方仍不推荐在大型链接项目中开启该选项
修改后为什么没生效？重启和路径写法细节
改完 settings.json 不生效，大概率卡在这两个地方：
- 必须重启工作区（Close Folder → Reopen Folder），热重载不触发 watcher 重建
-
"**/node_modules"写法无效；正确写法是"**/node_modules/**"（结尾双星号）或"**/node_modules/**/*" - 通配符区分大小写：Windows 下
"**/NODE_MODULES/**"不会匹配，Linux/macOS 默认也区分 - 工作区级配置（
.vscode/settings.json）优先级高于用户级，但若两者冲突，后者不会自动覆盖前者
最稳妥的做法：先清空 files.watcherExclude，只保留一条 "**/node_modules/**": true，确认生效后再逐条加其他路径——容易漏掉的不是逻辑，是斜杠和星号的位置。
