直接看「Process Explorer」定位瓶颈：按Ctrl+Shift+P执行Developer: Open Process Explorer，重点关注Extension Host（插件）、Shared Process（文件监听）和Search Service（搜索索引）三类进程；配合files.watcherExclude严格排除node_modules/dist等目录，并用子工作区替代全量加载。
怎么看 VSCode 启动和项目加载到底卡在哪
直接看「Process Explorer」——这是 VSCode 唯一自带、无需安装、能定位真实瓶颈的工具。按 Ctrl+Shift+P（Win/Linux）或 Cmd+Shift+P（macOS），输入并执行 Developer: Open Process Explorer，它会列出所有子进程的 CPU 和内存占用。重点关注三类条目：Extension Host（插件总控）、Shared Process（文件监听/搜索服务）、Search Service（全局搜索索引）。如果某个扩展在 Extension Host 中持续占 CPU >20%，基本就是它拖慢了项目加载。
files.watcherExclude 配不全，项目就永远“半加载”
VSCode 的文件监视器（chokidar）默认盯住整个工作区，一旦 node_modules 或 dist 里有文件变动（比如 npm install 或 webpack rebuild），它就会逐个发事件，导致 UI 线程卡顿、Git 状态刷新延迟、甚至保存失败。这不是“慢”，是“被压垮”。必须在项目根目录的 .vscode/settings.json 中强制排除：
"**/node_modules/**": true"**/dist/**": true"**/build/**": true"**/.git/**": true"**/logs/**": true- Python 项目加
"**/venv/**": true；前端加"**/out/**": true
注意：用户级设置（Settings UI 或 settings.json 在用户目录下）对大型项目无效；改完后必须关闭整个工作区再重新打开，否则不生效。
TS/JS 语言服务不是越“智能”越好
TypeScript 语言服务器（TSServer）在大型项目中默认尝试解析全部 node_modules 类型声明，极易引发内存暴涨和启动延迟。关掉这些非必要功能能立竿见影：
-
"typescript.tsserver.log": "off"（禁用日志，减少 I/O） -
"javascript.suggest.autoImports": false（关自动导入，避免全项目符号扫描） "typescript.preferences.includePackageJsonAutoImports": "off"- 更关键的是限制作用范围：
"typescript.preferences.suggestionActionsEnabled": false
如果项目已用 tsconfig.json，确保 include 字段只列源码路径（如 ["src/**/*"]），别留空或写 ["**/*"]——后者会让 TSServer 尝试加载整个工作区。
大项目别硬扛，用子工作区切出“最小可用环境”
一个含 50+ 包的 monorepo，打开根目录等于让 VSCode 同时加载所有包的类型定义、依赖图、Git 状态。正确做法是：右键点击某个子包（如 packages/core），选择 Add Folder to Workspace，然后另存为独立的 .code-workspace 文件。这样 VSCode 只初始化该子目录的扩展、语言服务和文件监听，启动时间可从 8 秒降到 1.2 秒。临时需要跨包跳转？用 Cmd+Click（macOS）或 Ctrl+Click（Win/Linux）仍可跳转，只是不主动索引其他包。
真正容易被忽略的是：很多团队把 files.exclude 和 search.exclude 配得非常细，却忘了 files.watcherExclude 才是防止 CPU 暴走的第一道闸门；而子工作区不是“功能阉割”，是把资源精准投向当前任务的最小可行策略。
