code --status是唯一可信起点，可立即列出Extension Host、tsserver等子进程的PID、CPU%和内存占用；需据此定位高占用进程，配置files.watcherExclude为"/node_modules/": true并彻底重启窗口。
VSCode空闲时 CPU 持续高占用，基本可以排除“你正在操作”导致的临时负载，问题一定出在后台子进程失控——Extension Host、rg（RipGrep）、tsserver、pyright 或 cpptools-srv 中至少有一个在持续满载，不是编辑器卡，是它“根本停不下来”。
怎么看哪个子进程真正在吃 CPU
别信任务管理器里那个泛泛的 Code Helper 进程，它是壳。真实干活的是子进程：
- 终端执行
code --status，直接列出所有子进程 PID、CPU%、内存和命令行参数 - 重点关注
Extension Host：CPU% 长期 >60%，说明某个插件（如esbenp.prettier-vscode或gitlens.gitlens）在后台反复解析或监听失败后死循环 - 看到
rg --files --hidden --follow占 400%+？八成是你打开了整个/home/xxx或C:\这类超大目录，rg正在递归扫描几万个小文件 -
tsserver或pyright占高？不是语言本身慢，是它正把整个node_modules/@types或 Python 依赖树加载进内存做全量类型推导
为什么禁用插件后 CPU 还下不去
VSCode 的插件禁用机制有陷阱：点 “Disable” 只阻止新加载，旧进程常驻不释放，尤其 ms-python.python、esbenp.prettier-vscode 这类注册了 onStartupFinished 的插件：
- 必须先运行命令面板
Developer: Show Running Extensions，确认目标插件确实在运行中 - 右键 →
Disable (For All Folders)（不是仅当前工作区） - 彻底关闭当前 VSCode 窗口（不是
Developer: Reload Window），再重新打开工作区 - Linux/macOS 下可补一刀：
ps aux | grep -i "pyright\|tsserver\|prettier"，找到残留 PID 后kill -9 [PID]
files.watcherExclude 配错等于没配
VSCode 默认用 chokidar 监听整个工作区，遇到 node_modules 这种几万小文件的目录，内核级 inotify 事件会爆炸式触发，Node.js 子进程持续 100% 跑——你什么都没干，CPU 就飙了：
- 必须写在项目根目录的
.vscode/settings.json中（不是用户级设置） - 通配符必须是
"**/node_modules/**": true，写成"*/node_modules/*"、"node_modules"或"/node_modules/"全无效 - 改完必须完全关闭并重开工作区，仅保存配置不生效
- Linux 用户若仍卡顿，检查
cat /proc/sys/fs/inotify/max_user_watches，低于524288就要调高
language server 降级比禁用插件更治本
Python 和 TypeScript 扩展不是“慢”，是默认太贪——Pylance 和 tsserver 设计上就为深度语义分析服务，中大型项目下内存驻留轻松破 1.2GB，CPU 拉高是必然结果：
- Python：把
python.languageServer从Pylance改为Jedi（Jedi 不加载全部依赖，只做基础补全） - TypeScript：关掉
typescript.preferences.includePackageJsonAutoImports，避免导入时反复解析node_modules/@types - ESLint：设
eslint.run为onType，并精简eslint.probe（比如去掉.json） - GitLens：关掉
gitlens.codeLens.enabled和gitlens.hovers.enabled，能降 30%–50% 内存
真正难处理的是那种“改了设置、禁了插件、重启了窗口，CPU 还是忽高忽低”的情况——往往是因为多个扩展叠加触发（比如 ESLint + Prettier + GitLens 同时监听保存事件），或者工作区路径本身就不该被打开（例如整个 ~/）。这时候得回到 code --status，盯住 PID 对应的完整命令行，才能揪出那个藏在后台、从不报错却永远在跑的进程。
