直接看code --status定位真实高负载子进程,结合ps -p [PID] -o args=确认扩展名;正确配置files.watcherExclude(双星号语法)、调高inotify限制、用二分法排查扩展,并精细调整语言服务器设置。

直接看 code --status,别猜进程、不重装、不盲禁——90% 的高 CPU 都能 2 分钟内定位到具体子进程和扩展。
怎么看哪个子进程真正在吃 CPU
任务管理器里那个 “Code Helper” 是壳,实际干活的是它下面的子进程。打开终端执行:
code --status
你会立刻看到类似这样的输出:
-
Extension Host: CPU% 82 —— 某个扩展(比如esbenp.prettier-vscode或gitlens.gitlens)在反复解析或监听失败后卡死 -
tsserver或pyright: 不是 TS/Python 本身慢,是正全量加载node_modules/@types做类型推导 -
Search进程内存 >300MB:八成是rg.exe在扫node_modules或符号链接目录 -
Shared Process占高:大概率是遥测、同步或自动更新在轮询,可临时加"telemetry.telemetryLevel": "off"验证
记下高占用进程的 PID,再用 ps -p [PID] -o args=(macOS/Linux)或任务管理器“详细信息”页右键 → “打开文件位置”,确认命令行里是不是含 pylance、prettier 等关键词。
为什么 files.watcherExclude 配了没用
VSCode 默认用 chokidar 递归监听整个工作区,node_modules 这种几万小文件目录一触发就是 inotify 事件风暴,Node.js 子进程直接满载——你什么都没干,CPU 就飙到 70%。
- 必须写在项目根目录的
.vscode/settings.json中(不是用户级设置) - 通配符必须是
"**/node_modules/**": true,写成*/node_modules/*、/node_modules/或node_modules全无效 - 配置后必须完全关闭当前 VSCode 窗口(不是重载),再重新打开工作区才生效
- Linux 用户若仍卡顿,检查
cat /proc/sys/fs/inotify/max_user_watches,低于524288就要调高
语言服务降级比禁用插件更稳
Python 和 TypeScript 扩展不是“慢”,是默认设计为深度语义分析。一个含 50+ 包的项目,Extension Host 内存轻松破 1.2GB,CPU 持续拉高是必然结果。
- Python:把
python.languageServer从Pylance改为Jedi(Jedi不加载全部依赖,只做基础补全) - TypeScript:设
typescript.preferences.includePackageJsonAutoImports为off,避免导入时反复解析node_modules/@types - ESLint:设
eslint.run为onType,并精简eslint.probe的文件类型(比如去掉.json) - GitLens:关掉
gitlens.codeLens.enabled和gitlens.hovers.enabled,能降 30%–50% 内存
禁用插件后 CPU 还高?进程没真正退出
点 “Disable” 只是阻止新加载,旧进程仍常驻内存。很多插件注册了 onStartupFinished 或 onLanguage:python,一旦激活就一直跑着。
- 先运行命令面板中的
Developer: Show Running Extensions,确认ms-python.python等确实在运行中 - 右键该插件 →
Disable (For All Folders)(注意不是仅当前工作区) - 必须完全关闭当前 VSCode 窗口(不是
Developer: Reload Window),再重新打开工作区 - 对 Python 项目,建议手动清理残留:
ps aux | grep -i "pyright\|python.*language",找到 PID 后kill -9 [PID]
最常被忽略的是:禁用后 settings.json 里还留着插件专属配置(如 "prettier.requireConfig"),这些字段仍可能触发后台检查;还有 .vscode/extensions.json 里的推荐项,一打开文件夹就会自动弹窗安装。


















