先运行code --status定位高占用extension host进程，再结合files.watcherexclude配置、语言服务优化及远程开发设置逐项排查；重点关注cpu%持续高于30%的扩展，通过developer: open process explorer实时验证并禁用异常扩展。
直接看 code --status 定位高占用 Extension Host 进程
VSCode 的 Extension Host 进程 CPU 持续 100%，不是“卡”，而是某个扩展在后台疯狂解析、监听或轮询。别猜，先用命令看真实进程：code --status 会列出所有子进程（包括每个 Extension Host 实例）的 PID、CPU% 和内存占用。重点关注 CPU% 高且持续不降的那行，记下它的 PID。
常见错误现象：code --status 显示某个 Extension Host 占用 85% CPU，但编辑器界面仍可操作——说明问题不在主 UI，而在该进程加载的某个扩展。
- macOS/Linux 下用
ps -p [PID] -o comm=查进程名，常能看到类似code-helper或带扩展 ID 的路径 - Windows 下打开任务管理器 → 详细信息 → 右键对应 PID → “转到服务”或“打开文件位置”，能定位到具体扩展目录
- 注意：多个
Extension Host进程可能共存（比如多窗口、远程连接），要逐个比对 CPU%
用 Developer: Open Process Explorer 实时观察扩展行为
Developer: Open Process Explorer 比 code --status 更直观，它在 VSCode 内部实时刷新，右侧直接显示每个扩展的 CPU% 和内存增长趋势。关键不是看“谁装了”，而是看“谁在动”。
使用场景：你刚保存一个文件，某扩展的 CPU% 突然跳到 60%，几秒后回落——这大概率是它绑定了 onSave 逻辑，且处理耗时过高。
- 重点关注名称含
eslint、prettier、gitlens、path-intellisense、ms-python.python的条目 - 如果某扩展 CPU% 持续 >30% 且无操作时也在爬升，基本可判定为异常行为源
- 右键该条目 → “Disable Extension” 后观察 CPU 是否立即回落，这是最快速的验证方式
检查 files.watcherExclude 是否漏掉构建产物目录
VSCode 默认用 chokidar 监听整个工作区，一旦 node_modules、dist、.git 或 build 目录没被排除，成千上万个文件变更事件就会触发扩展反复响应，导致 Node.js 子进程满载。
必须写进 settings.json，且语法严格：
"files.watcherExclude": {"**/node_modules/**": true, "**/dist/**": true, "**/build/**": true, "**/.git/**": true}- 通配符必须是双星号
**，写成*或*/node_modules/*无效 - Linux 用户还需检查内核限制：
cat /proc/sys/fs/inotify/max_user_watches，若低于 524288，需临时提升：sudo sysctl fs.inotify.max_user_watches=524288
针对 Python/TypeScript/C++ 扩展做轻量级配置
这些语言扩展默认启用全量类型推导和索引，面对大型项目极易吃光内存并拖垮 CPU。它们不是“bug”，是功能太重。
性能影响典型表现：打开含 50+ 包的 Python 项目，Extension Host 内存驻留超 1.2GB；TS 项目里 node_modules/@types 一多，语言服务器直接占满 2GB 内存。
- Python：
"python.analysis.extraPaths": []+"python.defaultInterpreterPath"显式指定解释器，避免自动扫描 - TypeScript：
"typescript.preferences.includePackageJsonAutoImports": "auto"改为"off"，禁用自动导入提示 - C/C++：
"C_Cpp.intelliSenseEngine": "Tag Parser"（非Default），并设置"C_Cpp.workspaceParsingPriority": "low"
真正容易被忽略的是：改完配置后必须重启 VSCode 窗口，而不是仅重载窗口或重启扩展——因为语言服务器进程不会热更新配置。
