code --status可按窗口维度列出所有Extension Host实例的PID、CPU%和内存，如Window[1]→CPU:82%、Window[3]→CPU:91%，重点关注CPU>60%且不回落的进程，再通过ps或任务管理器定位具体插件。
code --status 能一眼看出多个 Extension Host 进程谁在吃 CPU
多窗口打开时，每个窗口默认启动独立的 Extension Host 子进程，但任务管理器里只显示一个“Code Helper (Plugin)”——你根本分不清哪个窗口拖垮了 CPU。直接终端运行 code --status，它会按窗口（Window）维度列出所有 Extension Host 实例的 PID、CPU% 和内存，比如：
Window [1] (my-project) → Extension Host [12345] → CPU: 82% Window [2] (~) → Extension Host [12346] → CPU: 5% Window [3] (remote-ssh://server/app) → Extension Host [12347] → CPU: 91%
重点关注 CPU% >60% 且不回落的条目，再用 ps -p 12345 -o args=（macOS/Linux）或任务管理器右键 → “打开文件位置”（Windows）确认具体是哪个插件在跑。
Developer: Open Process Explorer 比 code --status 更适合盯实时波动
当你刚保存一个文件、切个标签页或触发 GitLens 提示，CPU 突然跳高又回落——code --status 可能抓不到瞬时峰值，而 Developer: Open Process Explorer 是实时刷新的。打开后注意：
- 按
CPU %列排序，长期 >30% 的扩展大概率绑定了onSave或onDidChangeTextDocument，比如esbenp.prettier-vscode或dbaeumer.vscode-eslint - 如果同一插件（如
ms-python.python）在多个窗口里都占高，说明它没做 workspace 隔离，而是全局索引整个node_modules - 右键某行 → “Copy Process Info”，粘贴出来看命令行末尾是否带
--stdio或--logLevel，这是语言服务器（pyright、tsserver）的典型特征
禁用插件必须按窗口粒度操作，不是全局 Disable 就完事
多窗口场景下，“Disable (For All Folders)”看似彻底，但实际只影响新窗口；旧窗口里的插件进程仍常驻——尤其 onLanguage:python 这类事件一触发就永驻。正确做法是：
- 先运行
Developer: Show Running Extensions，确认目标插件确实在高占用窗口里运行中 - 切换到那个具体窗口，再右键插件 → “Disable Extension in This Workspace”（不是全局 Disable）
- 关闭该窗口（不是 Reload），再重新用
File → Open Folder打开同一项目——否则旧Extension Host进程还在后台吃资源 - 若用了 Remote-SSH 或 WSL，还要单独进远程窗口执行一遍，因为远程和本地是两套
Extension Host实例
files.watcherExclude 在多窗口下容易漏配，必须逐个项目根目录设
你在一个窗口里配了 files.watcherExclude，不代表其他窗口也生效。VSCode 不继承用户级设置，只认当前工作区根目录下的 .vscode/settings.json。常见漏掉的情况：
- 打开的是用户主目录（如
/Users/xxx），里面含几十万文件，但没配"**/.git/**": true和"**/node_modules/**": true - Remote-SSH 窗口连的是服务器上的项目，但
.vscode/settings.json是本地的，远程根本读不到——得在远程项目根目录手动建一份 - 通配符写成
"node_modules/**"或"*/node_modules/*"，实际必须是"**/node_modules/**": true，少一个*都无效 - Linux/macOS 用户还需检查
cat /proc/sys/fs/inotify/max_user_watches，低于524288会导致 watcher 静默失败并反复重试，多窗口叠加后更明显
Extension Host、Search、pyright 都是独立进程，残留不清理，CPU 就永远压不下来。 
