VSCode打开大型项目卡顿主因是默认配置未裁剪：files.watcherExclude未配、search.exclude写错、非必要扩展未禁用；三者任一缺失均致CPU飙升、Ctrl+P延迟、保存卡顿。
VSCode 打开大型项目卡顿，90% 以上不是硬件问题，而是默认配置在监听和索引上“用力过猛”——files.watcherExclude 没配、search.exclude 写错、扩展没关，三者任一缺失都会让 CPU 持续飙高、Ctrl+P 延迟明显、保存变卡。
为什么 files.exclude 不能替代 search.exclude
files.exclude 只管左侧资源管理器是否显示文件夹，对 Ctrl+Shift+F 全局搜索完全无效。很多人把 "node_modules": true 加进 files.exclude 后发现搜索还是扫到 node_modules 里的文件，这不是 bug，是配置用错了地方。
-
search.exclude才真正控制搜索范围，必须显式配置，且路径必须带**/前缀（如"**/node_modules": true），写成"node_modules"或"node_modules/**"都不生效 - 多根工作区下，每个子文件夹的
search.exclude是独立生效的，不能靠根目录一条规则覆盖全部 - 如果同时用了搜索面板右上角的
files to exclude输入框，它会临时覆盖search.exclude的设置，适合一次性跳过某个临时目录
files.watcherExclude 配错会导致 inotify 耗尽
Linux/macOS 下 VSCode 默认用 inotify 监听文件变化，大型项目里未排除构建产物目录（如 dist、build、.next）会快速打满系统限制，触发 ENOSPC 或 watcher limit reached 报错——此时编辑器响应变慢、热更新延迟、甚至无法监听新文件。
-
files.watcherExclude的 glob 模式必须以**/开头（如"**/dist/**": true），否则不生效 - 它不支持
!取反语法，无法“排除所有但保留某一个”，这点容易误以为能精细控制 - 某些扩展（如 GitLens、ESLint 插件）会绕过该设置自行扫描，所以禁用非必要扩展比死磕配置更有效
哪些扩展必须关掉或调低优先级
扩展是性能杀手，尤其那些默认全量扫描项目的插件。不是所有“常用”扩展都适合大型项目。
- 立即禁用：
Auto Rename Tag、Path Intellisense、Bracket Pair Colorizer——它们在后台持续递归读取文件树，直接拖垮启动速度 - 可降级使用：
GitLens改为工作区禁用，或设"gitlens.advanced.fileWatcher.latency": 1000；ESLint关闭autoFixOnSave，改用命令手动触发 - 强制 TS 服务高优：
"extensions.experimental.affinity": { "ms-vscode.vscode-typescript-next": 2 }，避免被其他扩展抢占资源
typescript.preferences.includePackageJsonAutoImports 关不掉就白优化
这个设置默认开启，会让 TypeScript 语言服务主动解析 package.json 中所有依赖的类型定义，大型 monorepo 里可能拉入上千个 @types/* 包，导致首次加载卡住 2–5 分钟。关闭后智能提示依然可用，只是不自动补全未显式导入的包名。
- 在工作区
.vscode/settings.json中加："typescript.preferences.includePackageJsonAutoImports": "off" - 同步关闭
"typescript.tsserver.log": "off"和"javascript.suggest.autoImports": false，减少语言服务冗余行为 - 若项目用了
tsconfig.json的references，确保只 include 当前模块，避免跨包全量解析
最常被忽略的一点：所有这些配置都必须写进项目根目录的 .vscode/settings.json，而不是用户全局设置。工作区设置不生效？检查右下角是否显示「工作区设置」——否则你改的全是别人的事。
