VSCode CPU 占用高主因是扩展或文件监听失控，非编辑器本身问题；通过进程排查、禁用可疑扩展、关闭 node_modules 监听三步可降至 5% 以下。
VSCode CPU 占用高，90% 以上是扩展或文件监听失控导致的，不是编辑器本身有问题。直接看进程、禁用可疑扩展、关掉 node_modules 监听，三步就能压到 5% 以下。
怎么看哪个进程在吃 CPU
别只盯着任务管理器里一个 Code Helper 进程——它只是壳，真干活的是后台子进程。打开命令面板（Ctrl+Shift+P 或 Cmd+Shift+P），执行 Developer: Open Process Explorer。重点盯三列：
-
Extension Host：超 500MB 或 CPU% 长期 >30%，说明某个插件在后台死循环或持续解析 -
Search：持续 >300MB，大概率是rg.exe（RipGrep）在扫node_modules或符号链接目录 - 名字带
cpptools-srv、tsserver、pyright的进程：对应 C/C++、TS、Python 语言服务，一卡就是它们在全量索引
顺手再跑一次 code --status 终端命令，它会直接列出各进程 PID 和 CPU%，比系统工具更准。
怎么快速定位问题插件
盲目禁用所有扩展效率低，还容易漏掉“已禁用但进程仍在”的情况。推荐两个实操路径：
- 先运行
Developer: Show Running Extensions，按 CPU 时间排序，记下前两名插件 ID（比如esbenp.prettier-vscode、gitlens.gitlens） - 右键该插件 →
Disable (For All Folders)，然后必须关闭并重新打开整个 VSCode 窗口（不是重载），否则旧进程不释放 - 更省事的二分法：命令面板输入
Extensions: Bisect Extensions，按提示重启、验证、缩小范围，3–4 轮就能锁死单个插件
高频嫌疑对象：ESLint、Prettier、GitLens、Auto Rename Tag、MarsCode。特别是 ESLint + Prettier 同时启用时，保存即触发双重格式化+校验，CPU 直接拉满。
为什么关掉 node_modules 监听能立竿见影
VSCode 默认用 chokidar 递归监听整个工作区，遇到 node_modules 这种几万小文件的目录，内核级 inotify 事件会爆炸式触发，Node.js 子进程持续满载——你什么都没干，CPU 就飙到 70%。
- 在项目根目录的
.vscode/settings.json里加这段：
"files.watcherExclude": {
"**/node_modules/**": true,
"**/dist/**": true,
"**/build/**": true,
"**/.git/**": true
},
"search.exclude": {
"**/node_modules/**": true,
"**/dist/**": true,
"**/build/**": true
}
注意：**/node_modules/** 必须是双星号，写成 */node_modules/* 无效；Linux 用户如果还卡，检查 fs.inotify.max_user_watches 是否过低，需手动调高。
语言服务配置不当也会拖垮 CPU
typescript-language-features 和 ms-python.python 不是“慢”，是默认开启全量语义分析，把整个 node_modules/@types 或依赖包树都加载进内存。中大型项目里，这俩常驻内存轻松破 1.2GB。
- TypeScript：关掉自动导入和类型推导，在设置里加
"typescript.suggest.autoImports": false，再设"typescript.preferences.includePackageJsonAutoImports": "off" - Python：把
python.languageServer从Pylance切成Jedi（轻量但功能少），或临时禁用python.analysis.extraPaths指向的巨量路径 - C/C++：用
"C_Cpp.files.exclude"排除**/third_party和**/build，避免索引无关代码
改完任何一项设置，都得重启 VSCode 窗口才生效——这点最容易被忽略，改了没反应，其实是进程没换新配置。
