VSCode CPU过高主因是扩展、文件监听或语言服务器失控，应先运行code --status定位高占用进程：Extension Host持续>60%说明插件异常，Search内存>300MB表明rg.exe扫描node_modules，含pyright/tsserver等进程则指向语言服务全量索引。
VSCode 占用 CPU 过高，90% 以上不是编辑器本身的问题，而是某个扩展、文件监听器或语言服务器在后台失控运行——直接查 code --status 就能定位真凶，比瞎禁插件快得多。
怎么看哪个进程在疯跑
code --status 是唯一该先跑的命令。它不依赖 UI 响应，直接列出所有子进程的 PID、CPU% 和内存占用。重点关注这几类：
-
Extension Host：CPU > 60% 且持续不降 → 某个插件在轮询、反复解析或监听失败后卡死 -
Search进程内存 > 300MB →rg.exe（RipGrep）正在扫node_modules或符号链接目录 - 名字含
pyright、tsserver、cpptools-srv的进程 → Python/TS/C++ 语言服务在全量索引依赖树 -
Shared Process占高 → 遥测（telemetry.telemetryLevel）、设置同步或自动更新在后台轮询
记下高占用进程的 PID，再用 ps -p [pid] -o comm=（macOS/Linux）或任务管理器“详细信息”页看完整命令行，能直接看到是哪个扩展启动的，比如 esbenp.prettier-vscode 或 ms-python.python。
为什么禁用插件后 CPU 还不降
禁用操作只是阻止新加载，旧进程不会退出。很多插件注册了 onStartupFinished 或 onLanguage:python 等激活事件，一旦触发就会常驻内存。
- 先运行命令面板中的
Developer: Show Running Extensions，确认哪些插件真在跑 - 右键目标插件 →
Disable (For All Folders) - 必须完全关闭当前 VSCode 窗口（不是重载），再重新打开工作区
- 对 Python/TS 项目，可手动清理残留：
ps aux | grep -i "pyright\|tsserver\|python.*language"，找到 PID 后kill -9 [PID]
files.watcherExclude 配错等于没配
VSCode 默认用 chokidar 递归监听整个工作区，遇到 node_modules（几万小文件）、dist、.git 时，inotify 句柄会持续增长且几乎不回收——这是最隐蔽的 CPU 爬升来源。
- 路径通配符必须是
"**/node_modules/**": true，写成*node_modules*或/node_modules/无效 - 配置只影响文件变更监听，和
search.exclude无关；后者只过滤搜索结果，不减 CPU - 生效需关闭并重新打开工作区，仅保存
settings.json不够 - Linux 用户若仍卡顿，检查系统限制：
cat /proc/sys/fs/inotify/max_user_watches，低于524288建议调高
语言服务器吃内存不是慢，是默认太“贪”
Python 扩展（ms-python.python）和 TypeScript 内置语言服务不是“慢”，是默认把整个依赖树加载进内存做类型推导。一个含 50+ 包的 Python 项目，Extension Host 常驻内存轻松破 1.2GB；TS 项目里 node_modules/@types 一多，语言服务器直接吃光 2GB。
- Python：把
python.languageServer从Pylance改为Jedi（Jedi 不做全量语义分析） - TypeScript：关掉
typescript.preferences.includePackageJsonAutoImports，避免 npm 包导入时反复解析 - ESLint：设
eslint.run为onType，并精简eslint.probe的文件类型（比如去掉.json） - GitLens：关掉
gitlens.codeLens.enabled和gitlens.hovers.enabled，能降 30%–50% 内存
真正容易被忽略的是：这些配置改完后必须重启窗口，而且某些语言服务器（如 Pylance）还会缓存索引，首次打开大项目时延迟依然明显——这不是 bug，是设计如此。
