VSCode定位高CPU进程需先运行code --status查看Extension Host、Search等子进程PID及CPU%，再结合Developer: Open Process Explorer分析extensionHost下各插件RSS内存，禁用问题插件后必须重启Extension Host或重开窗口，同时配置files.watcherExclude排除node_modules。
VSCode 本身不直接暴露系统级 CPU 占用数据，但能准确定位到哪个进程（编辑器主进程、Extension Host、语言服务器、测试子进程等）在吃 CPU。关键不是“看总占用”，而是“锁定具体罪魁祸首”。
Developer: Open Process Explorer 查 Extension Host 真实内存与 CPU
这是最轻量、最可靠的起点：它绕过系统任务管理器的干扰，只显示 VSCode 自己启动的进程。打开命令面板（Ctrl+Shift+P），输入并执行 Developer: Open Process Explorer。
- 重点关注
Extension Host进程的CPU和Memory列——如果空载时仍持续 >20% CPU 或内存缓慢爬升，基本可判定是某个扩展泄漏或轮询失控 - 若
Shared Process或Window进程 CPU 高，说明是 VSCode 渲染层或 Electron 主线程被阻塞，常见于大量 DOM 操作（如 Webview 插件未销毁）或插件同步阻塞调用 - 注意区分“瞬时尖峰”和“持续高位”：语言服务器首次索引项目时 CPU 高是正常的；但保存文件后 10 秒内仍不回落，就是问题
Developer: Show Running Extensions 看扩展启动与运行耗时
该命令列出所有已加载扩展的实时行为，比 Process Explorer 更细粒度地揭示“谁在拖慢启动和响应”。
- 按
Startup Time排序，>500ms 的扩展大概率是首屏卡顿元凶（尤其 Python、TypeScript、ESLint 类语言服务） - 看
Activation Time：某些扩展在打开特定文件类型（如.py、.ts）时才激活，此时 CPU 飙升就和它强相关 - 检查
Runtime列是否标为blocked on main thread——这表示它在主线程执行了同步耗时操作（比如读大文件、正则全量匹配），必须优化或换异步方案
终端里用 top/htop 直接抓 test / tsserver / code-server 进程
当怀疑是测试运行、类型检查或 Remote-SSH 导致卡顿时，跳过 VSCode UI 层，直连系统进程视图。
- Linux/macOS：在集成终端运行
top -b -n1 | grep -E "(jest|pytest|tsserver|code-server|node)"，观察 %CPU 和 RES（内存） - Windows：用
tasklist /fi "imagename eq node.exe" /fo list，再结合Get-Process node | Sort-Object CPU -Descending | Select -First 3 - 特别注意
tsserver进程是否长期占满单核（>95%），这通常是因为typescript.preferences.disableAutomaticTypeAcquisition未关闭，导致它持续扫描node_modules - Remote-SSH 场景下，
code-server进程 CPU 高，大概率是本地扩展（如 GitLens）在远程端同步触发了高频 fs watch
禁用扩展后 CPU 不降？你没真正重启进程
禁用扩展只是让 VSCode 下次启动时不加载它，旧的 Extension Host 进程仍驻留并持有全部资源。很多排查失败，就卡在这一步。
- 禁用可疑扩展（如
GitLens、ms-python.python、esbenp.prettier-vscode）后，必须关闭当前 VSCode 窗口，再全新打开一个窗口（不要Reload Window） - 如果用了 Dev Container，
Extension Host进程实际跑在容器内，需进容器执行pkill -f "extensionHost"才算彻底清理 - 验证是否生效：打开
Developer: Open Process Explorer，确认Extension Host进程 PID 已变，且 CPU / Memory 回落至空载基线（通常
