必须同时配置search.exclude和files.watcherexclude，前者控制搜索时跳过文件，后者阻止启动时监听，缺一不可；正确写法为"/node_modules/"，修改后需关闭并重新打开工作区才生效。
search.exclude 和 files.watcherExclude 必须同时配
只配 search.exclude，VSCode 搜索时确实不读那些目录，但启动时文件监视器（watcher）仍在疯狂监听 node_modules 里的几万个文件——CPU 占用高、搜索面板打开慢、甚至卡死。真正生效要靠双保险：search.exclude 控制“搜的时候跳过”，files.watcherExclude 控制“一开始就不盯”。
常见错误写法："node_modules" 或 "**/node_modules" —— 这些不会递归排除子目录，正确写法是 "**/node_modules/**"（结尾的 /** 表示整棵子树）。dist、.git、.next 同理。
- 修改后必须关闭并重新打开整个工作区（不是仅关窗口），否则
files.watcherExclude不生效 -
files.watcherExclude支持文件类型，比如"**/*.log"很有必要：一个 2GB 的日志文件就能让 watcher 队列阻塞数秒 - 硬链接或符号链接路径容易漏掉，建议额外加
"**/node_modules/**"和"**/node_modules"双重保险
通配符写错会导致排除完全失效
search.exclude 和 files.watcherExclude 都依赖 glob 模式匹配，而 VSCode 对路径匹配非常严格。比如：
-
"**/node_modules"→ 只排除顶层node_modules目录，嵌套的（如packages/foo/node_modules）仍会被扫 -
"node_modules/**"→ 只匹配项目根下直接叫node_modules的路径，不跨级 -
"**/node_modules/**"→ ✅ 正确：任意深度下的node_modules目录及其全部内容
其他高频误配："dist"（漏掉 build）、"*.log"（只匹配当前目录，应写 "**/*.log"）、"coverage"（没加 /**，子目录仍被监听）。
临时大文件比配置更难防
即使配置全对，开发中生成的临时文件（比如本地导出的 report.json、调试 dump 的 heap.out、未被 .gitignore 覆盖的构建产物）仍会进搜索范围。这类文件往往单个就几百 MB，I/O 等待直接拖垮搜索。
- 最稳的兜底方式：搜索前手动点击搜索框右上角的文件夹图标，选择具体源码目录（如
src/或packages/core/），绕过所有配置风险 -
search.useIgnoreFiles设为true可自动遵循.gitignore，但注意它只影响search.exclude，不影响files.watcherExclude - 如果项目用了 monorepo 工具（如 pnpm workspace），
node_modules可能出现在多层，务必确认"**/node_modules/**"能覆盖所有位置
search.maxFileSize 是防止卡死的最后一道闸
VSCode 默认不限制单个文件大小，遇到巨型日志或打包产物（如 vendor.js 30MB+）时，主线程会卡在读取和正则扫描上。加这一行能立竿见影：
{
"search.maxFileSize": 5
}
单位是 MB，设为 5 表示跳过所有大于 5MB 的文件。注意这不是“排除”，而是“跳过读取”——它不改变 search.exclude 的路径逻辑，但能防止大文件把搜索进程拖死。
- 值太小（如
1）可能误跳过合理的大型源码文件（如某些数据驱动的 JSON Schema） - 值太大（如
50）起不到保护作用，尤其在 SSD 性能一般或内存紧张时 - 该配置只对
search.exclude未覆盖到的文件生效，优先级低于排除规则
真正卡顿的根源，往往不是 VSCode 太慢，而是你让它去读本不该读的东西。配置写对只是第一步，关键得理解每条规则在哪个环节起效、在哪种场景下会失效。
