VSCode性能问题应优先使用Developer: Open Process Explorer定位高耗扩展，重点关注Memory列>200MB或CPU持续>10%的第三方插件，禁用后需执行code --disable-extension或--no-extensions彻底清理残留进程。
VSCode性能问题大多能通过内置工具快速定位，不需要猜、不用重装。 内置的 Developer: Open Process Explorer 就是核心入口，它直接暴露各扩展的真实资源消耗，比看任务管理器准得多。
Process Explorer 找不到高耗资源扩展
这是最常被忽略的第一步。很多人打开后只扫一眼就关掉，但关键信息藏在细节里：
- 内存列（Memory）超过 200 MB 的第三方扩展大概率是罪魁祸首，比如
Auto Import常驻 250+ MB - CPU 列持续高于 10% 且线程数（Threads）长期 > 5，说明它在后台做重计算（如 AST 全量解析）
- 注意区分
ms-*官方扩展（如ms-python.python）和社区扩展（如rbbit.typescript-hero），前者通常更可控
禁用扩展后重启仍卡顿
禁用不等于卸载，残留进程可能还在运行。必须执行硬性清理：
- 终端中运行
code --disable-extension "publisher.extension-id"（替换为实际 ID），比 GUI 禁用更彻底 - 执行
code --no-extensions启动纯净模式，确认是否恢复流畅——若恢复，说明问题确实在扩展 - 某些扩展（如
Prettier）即使禁用，其语言服务器进程仍可能残留，需手动在 Process Explorer 中右键 Kill
files.watcherExclude 和 search.exclude 配置无效
这两个配置项最容易写错路径格式，导致文件监视器照常过载：
-
"files.watcherExclude"必须用双星号通配符，例如"**/node_modules/**"，写成"node_modules"或"./node_modules"都无效 -
"search.exclude"不影响文件监视，只控制搜索范围；要减负必须两者都配 - Windows 用户特别注意反斜杠转义：路径中不能出现
\，一律用/，否则 VSCode 解析失败
启动慢但 Process Explorer 显示正常
这说明瓶颈不在扩展，而在初始化阶段。冷启动问题需要更底层的诊断：
- 用
code --prof-startup --prof-startup-file=profile.log启动，生成 V8 CPU Profile 日志 - 将
profile.log拖入 Chrome 浏览器的chrome://tracing分析，重点看require和compile阶段耗时 - 常见陷阱：工作区根目录下存在超大日志文件（如
app.log超过 500MB），VSCode 会尝试读取其编码类型，阻塞主线程
真正难排查的不是“哪个扩展卡”，而是“为什么禁用了还卡”——往往因为配置没生效、进程没清干净，或冷启动时加载了不该加载的文件。盯住 Process Explorer 的实时数据，比任何经验判断都可靠。
