vs code插件不遵守files.exclude，需单独配置插件自身排除规则；如eslint用ignorepatterns、gitlens用gitlens.advanced.filesearch.exclude，否则仍会扫描node_modules等目录。
插件本身不直接控制 files.exclude，得看它是否读取这个配置
VS Code 插件（比如 ESLint、GitLens、Prettier）默认不会主动遵守 files.exclude，它们通常按需读取文件系统——哪怕你把 node_modules 从资源管理器藏起来了，ESLint 仍可能扫描里面的所有 .js 文件做校验。
真正起作用的是插件自己的配置项，不是全局的 files.exclude。比如：
-
eslint.enable控制是否启用，但不决定扫描范围 -
eslint.workingDirectories才能指定它只检查哪些子目录 -
gitlens.advanced.fileSearch.exclude是 GitLens 自己的排除规则，和search.exclude无关
所以别指望改了 files.exclude 就能让插件“自动跳过”某些文件夹——除非文档明确写了它会复用该设置（极少数插件如 Search Editor 会，但 ESLint 不会）。
想让插件跳过 node_modules 或 dist？优先改插件配置，不是 files.exclude
以 ESLint 为例，如果你发现它在 node_modules 里报错或卡顿，说明它正在扫描不该扫的地方。这时候要动手的是它的配置，不是 VS Code 的通用设置：
- 在项目根目录加
.eslintrc.js，用ignorePatterns显式排除：{"ignorePatterns": ["**/node_modules/**", "**/dist/**"]} - 或者在
package.json的eslintConfig字段里写同样内容 - VS Code 的
eslint.options.cwd可以限定工作目录，避免它向上遍历到父级node_modules
同理，Prettier 有 prettier.ignorePath 指向自定义 .prettierignore；TypeScript 插件靠 tsconfig.json 的 exclude 字段；GitLens 则要配 gitlens.advanced.fileSearch.exclude。
files.exclude 和 search.exclude 对插件没用，但会影响“快速打开（Ctrl+P）”
files.exclude 真正影响的是 VS Code 自身 UI 层：资源管理器、Ctrl+P（快速打开）、Ctrl+Shift+P（命令面板）里的文件路径补全。插件调用底层 API 读文件时，基本不受限。
- 你在
Ctrl+P里输main，不会列出node_modules/react/main.js—— 因为files.exclude已让它“不可见” - 但 ESLint 启动时直接调用 Node.js 的
fs.readdirSync，照样能读到那些路径 - GitLens 在侧边栏显示“最近修改文件”，如果某个文件被
files.exclude隐藏了，它依然可能出现在列表里（取决于它是否绕过 VS Code 的文件服务）
所以验证插件是否真跳过了某目录，不能只看左边文件树空不空——得关掉插件、再开、观察输出面板日志或 CPU 占用是否下降。
插件配置容易漏掉的坑：路径写法、继承关系、版本兼容性
很多插件的 exclude 规则看着像 glob，实际解析逻辑各不相同：
-
eslint.ignorePatterns支持**/dist/**，但不支持!node_modules/@types/**这种否定语法（ESLint v8.56+ 才开始实验性支持） -
prettier.ignorePath默认指向.prettierignore，但如果该文件不存在，它不会 fallback 到.gitignore，也不会读files.exclude -
typescript.preferences.include和exclude是相对tsconfig.json路径的，不是工作区根——写"../node_modules"可能出错 - 某些旧版插件（如老版本 GitLens）把
**/build解析成正则，导致build-2024也被误杀
最稳妥的做法：查插件官网文档里 “ignore” 或 “exclude” 关键词，复制示例配置，然后在插件输出面板里看它加载时打印的实际扫描路径——这才是唯一真实依据。
