“扩展进程占用过高”是Extension Host失控信号，需用Developer: Open Process Explorer查CPU%＞30%的插件，禁用后必须重启窗口，配合files.watcherExclude配置（如"/node_modules/": true）和语言服务优化。
“扩展进程占用过高”不是警告，是 Extension Host 进程已失控的明确信号——它通常意味着某个插件在后台持续解析、轮询或监听失败后卡死，必须立刻定位 PID 并终止对应子进程，否则 CPU/内存会持续爬升。
怎么看哪个扩展在疯跑
别信任务管理器里那个“Code Helper”，它只是壳。真正干活的是 Extension Host 子进程，得用 VSCode 自己的诊断入口看：
- 按
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS），输入并执行Developer: Open Process Explorer - 重点关注 “CPU %” 列：长期 >30% 的
Extension Host行，右键 → “Copy Process Info”，粘贴出来看完整命令行 - 命令行里带
esbenp.prettier-vscode、gitlens.gitlens、ms-python.python或dbaeumer.vscode-eslint的，基本就是它 - 顺手再开终端跑一次
code --status，它比系统工具更准，直接标出各进程 PID 和实时 CPU%
禁用插件 ≠ 停止进程，重启窗口才是关键
很多插件（尤其是语言服务类）一旦激活就常驻不退，点“Disable”只阻止下次加载，旧进程照常吃资源：
- 先运行
Developer: Show Running Extensions，确认哪些插件真在跑、占多少 CPU/内存 - 右键目标插件 →
Disable (For All Folders)（不是仅当前工作区） -
必须完全关闭当前 VSCode 窗口（macOS 要退出菜单栏图标），再重新打开项目——
Developer: Reload Window没用 - 对 Python/TS 项目，可手动清理残留：
ps aux | grep -i "pyright\|tsserver\|python.*language"，找到 PID 后kill -9 [PID]
files.watcherExclude 写错等于没配
VSCode 默认用 chokidar 监听整个工作区，遇到 node_modules 这种几万小文件的目录，内核级 inotify 句柄会持续增长且几乎不回收——这不是插件问题，是系统级泄漏：
- 路径通配符必须是
"**/node_modules/**": true，写成*node_modules*、/node_modules/或node_modules/**都无效 - 生效必须关闭并重新打开工作区，仅保存
settings.json不够 - 必加项：
"**/node_modules/**": true、"**/dist/**": true、"**/.git/**": true、"**/*.log": true - Linux 用户若仍卡顿，检查
cat /proc/sys/fs/inotify/max_user_watches，低于524288就要调高
Python/TypeScript 语言服务不是慢，是默认全量索引
它们不是“卡”，是试图把整个依赖树加载进内存做类型推导，一个含 50+ 包的 Python 项目，Extension Host 内存轻松破 1.2GB：
- Python：把
python.languageServer从Pylance改为Jedi，或关掉python.analysis.extraPaths - TypeScript：关掉
typescript.preferences.includePackageJsonAutoImports，避免 npm 包导入时反复解析 - ESLint：设
eslint.run为onType，并精简eslint.probe（比如去掉.json） - GitLens：关掉
gitlens.codeLens.enabled和gitlens.hovers.enabled，能降 30%–50% 内存
最常被忽略的一点：AI 类插件（如 tongyi lingma）默认会对整个工作区做代码索引，且不随 files.watcherExclude 生效——这类插件要么关掉索引，要么彻底卸载，否则优化其他项效果有限。
