VSCode CPU 占用过高通常由扩展后台异常、文件监听风暴或语言服务导致；优先用 code --status 定位高耗进程，再通过 Extensions: Bisect Extensions 二分排查，配合 .vscode/settings.json 排除 node_modules 监听及调整语言服务器配置。
VSCode CPU 占用过高，八成是某个扩展在后台疯狂轮询、解析或监听文件，而不是编辑器本身“太重”。直接定位进程比盲目禁用更省时间。
用 code --status 看清谁在吃 CPU
终端里执行 code --status，它会列出所有子进程（Extension Host、Renderer、Search）的实时 CPU 和内存占用。重点关注 Extension Host 进程的 CPU% —— 如果持续高于 70%，说明某个扩展逻辑异常；若 Search 占高，大概率是 rg.exe（RipGrep）正在扫描 node_modules 或符号链接目录。
-
code --status输出中带 PID 的行，可配合ps -p [PID] -o comm=（macOS/Linux）或任务管理器（Windows）确认具体是哪个扩展进程 - 别只看 VSCode 主窗口响应是否流畅——界面正常但
Extension Host占 90% CPU，问题一定出在插件后台逻辑 - 该命令必须在 VSCode 已启动且 CPU 高时运行，否则看不到真实负载
用二分法快速锁定问题扩展
逐个禁用扩展效率低，Bisect Extensions 是官方内置的二分排查流程，3–4 轮就能缩到单个扩展。它比手动试错快一个数量级，尤其适合装了 20+ 插件的用户。
- 打开命令面板（
Ctrl+Shift+P或Cmd+Shift+P），输入并选择Extensions: Bisect Extensions - 每次重启后观察 CPU 是否回落：回落 → 问题扩展在已禁用的一半中；未回落 → 继续对剩余启用的一半二分
- 常见高嫌疑扩展：
esbenp.prettier-vscode、gitlens、ms-python.python、marscode，尤其是启用了onSave或实时符号分析的版本 - 禁用后必须重启整个窗口（不是重载），否则旧进程不会释放
关掉 node_modules 的文件监听
VSCode 默认递归监听整个工作区，遇到含几万小文件的 node_modules 目录，内核级 inotify/fsevents 事件风暴会直接拉高 CPU，和插件无关。
- 在项目根目录的
.vscode/settings.json中添加：
{
"files.watcherExclude": {
"**/node_modules/**": true,
"**/dist/**": true,
"**/build/**": true,
"**/.git/**": true
}
}
settings.json —— 工作区级配置才能精准控制监听范围files.useExperimentalFileWatcher 是否为 false；新版默认开启实验监听器，某些场景反而更耗资源语言服务与渲染器的轻量切换
TypeScript 和 Python 的语言服务器默认做全量语义分析，中大型项目下初始化慢、驻留内存高；VSCode 1.85+ 的 WebAssembly 文本渲染器对老 CPU 也可能造成主线程争抢。
- Python 用户可将
python.languageServer改为Jedi（而非Pylance）；TypeScript 用户可设typescript.preferences.includePackageJsonAutoImports为off - 如需彻底禁用新渲染器，在
argv.json（通过Preferences: Configure Runtime Arguments打开）中加："disable-webassembly-text-renderer": true -
C_Cpp用户可调低解析优先级："C_Cpp.workspaceParsingPriority": "low"，避免拖慢主进程 - 这些改动都需重启 VSCode 才生效，且效果因项目规模差异明显——小项目可能无感，大项目立竿见影
真正难处理的是那些“禁用后仍驻留”的语言服务器进程，比如 Pylance 或 tsserver，它们不随插件开关而退出，得手动 kill -9 对应 PID 再验证。这点容易被忽略，但恰恰是 CPU 持续飙高的关键断点。
