VSCode高CPU占用90%以上源于后台子进程而非编辑器本身，用code --status可精准定位Extension Host、pyright等高耗进程，配合files.watcherExclude配置、语言服务器降级（如Pylance→Jedi）及二分法排查扩展即可高效解决。
VSCode项目高CPU占用，90%以上不是编辑器本身的问题，而是某个后台子进程在疯跑——code --status 一眼就能定位真凶，不用猜、不重装、不盲目禁用插件。
怎么看哪个进程在吃CPU
别信任务管理器里一堆“Code Helper”——它们只是壳。真正干活的是子进程，比如 Extension Host、pyright、tsserver 或 rg.exe。
- 终端直接运行
code --status，它会列出所有子进程的 PID、实时CPU%和内存占用 - 重点关注
Extension Host：如果长期 >60%，基本锁定是某个扩展（如ms-python.python、esbenp.prettier-vscode）在反复解析或监听失败后卡死 - 看到
pyright或tsserver占高？不是语言本身慢，是它正在全量加载node_modules/@types或整个依赖树做类型推导 - 记下高占用进程的 PID，再用
ps -p [PID] -o args=（macOS/Linux）或任务管理器“详细信息”页右键 → “打开文件位置”，确认命令行是否含pylance、pyright、eslint等关键词
为什么 files.watcherExclude 配了也没用
VSCode 默认用 chokidar 递归监听整个工作区，遇到 node_modules（几万小文件）、dist、.git/objects 就触发 inotify 事件风暴，Node.js 子进程满载——你什么都没干，CPU 就飙到 100%。
- 必须写在项目根目录的
.vscode/settings.json中，不是用户级设置 - 通配符必须是
"**/node_modules/**": true，写成*node_modules*、/node_modules/或node_modules全无效 - 配置后必须完全关闭当前 VSCode 窗口（不是“重载窗口”），再重新打开该工作区才生效
- Linux/macOS 用户若仍卡顿，检查
cat /proc/sys/fs/inotify/max_user_watches，低于524288就要调高：sudo sysctl fs.inotify.max_user_watches=524288
Python项目CPU高，别急着禁用插件
Python 扩展不是“慢”，是默认太贪——Pylance 试图全量索引整个依赖树，中大型项目下 Extension Host 内存轻松破 1.2GB，CPU 持续拉高是必然结果。
- 降级语言服务器比禁用插件更实用：把
python.languageServer从Pylance改为Jedi（Jedi不加载全部依赖，只做基础补全） - 禁用插件必须彻底：点“Disable”只是阻止新加载，旧进程仍常驻内存；需先运行命令面板中的
Developer: Show Running Extensions，确认ms-python.python在运行中，右键 →Disable (For All Folders)，然后**完全关闭窗口**再重开 - 手动清理残留：执行
ps aux | grep -i "pyright\|python.*language"，找到 PID 后kill -9 [PID] - 避免打开整个磁盘或用户主目录——只打开真正需要编辑的子文件夹，否则
files.watcherExclude再准也拦不住底层事件爆炸
扩展太多时怎么快速定位问题源
一个一个禁用太慢，VSCode 内置了二分法排查机制，几轮就能缩到单个扩展。
- Ctrl+Shift+X → 右上角 ⋯ →
Bisect Extensions - 它会自动禁用一半扩展、重启窗口，让你判断 CPU 是否回落；再根据反馈继续二分，通常 3–4 轮就能锁定罪魁祸首
- 常见高开销扩展包括：
GitLens（尤其开启gitlens.hovers.enabled）、ESLint（设为onType可大幅缓解）、Prettier（保存时嵌套触发易卡死） - 顺手查一下
Developer: Startup Performance，看哪些扩展启动就耗时过长，这类往往也是长期驻留的内存大户
真正容易被忽略的点是：files.watcherExclude 配错路径、没关窗口、没清残留进程，三者只要漏一个，所有配置都白搭；而 code --status 是唯一能绕过表象直击真实子进程的诊断入口——别跳过它。
