VSCode 自带性能监控能力已足够可靠，无需安装第三方插件；因其轮询系统接口反而增加2–5% CPU及内存开销，且无法访问内核级数据，真实瓶颈应通过Developer: Open Process Explorer、Extension Host日志和Memory快照协同定位。
VSCode 自身已内置足够可靠的性能监控能力，不需要额外装“性能监控插件”——装了反而增加开销、干扰判断。
为什么不该依赖第三方性能监控插件
多数标榜“监控 CPU/内存”的插件（如 vscode-monitor-pro、system-monitor）本质是轮询系统接口并渲染图表，它们本身就会持续占用 2–5% CPU 和几十 MB 内存。当你怀疑 VSCode 卡顿时，这类插件正在成为问题的一部分，而非解决方案。
真实瓶颈通常来自：扩展主机（Extension Host）卡死、语言服务器（如 typescript-language-server）高负载、或某个插件在后台反复解析大文件。这些，原生工具就能准确定位。
- 插件无法访问 VSCode 内核级进程数据（比如渲染进程阻塞、IPC 延迟），只能读取操作系统层面的粗粒度指标
- 多个监控插件同时运行会竞争
process.cpuUsage()和process.memoryUsage()调用，放大抖动 - 图表渲染本身依赖 WebView，容易触发 Chromium 渲染线程争抢，尤其在多窗口编辑时
用好 VSCode 自带的 Developer: Open Process Explorer
这是最直接、零成本、无侵入的诊断入口。它显示的是真实进程级资源占用，不是估算值。
- 按
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS），输入Developer: Open Process Explorer - 重点关注
Extension Host进程的CPU和Memory列：若长期 >15% CPU 或 >500MB 内存，说明有插件异常 - 右键某扩展名 →
Disable Extension，无需重启即可卸载影响源；再观察数值是否回落 - 注意区分
Shared Process（负责 PDF/Markdown 预览等）和GPU Process（仅当启用硬件加速时存在）
配合 Developer Tools 的 Memory 面板抓内存泄漏
当某个插件疑似吃内存（比如打开大 .drawio 文件后不释放），必须用堆快照交叉比对。
- 打开
Developer: Toggle Developer Tools→ 切到Memory标签页 - 点
Take heap snapshot，操作一次疑似泄漏行为（如打开/关闭绘图文件），再拍一张 - 切换快照 → 点上方
Comparison→ 看Objects Count列中增长最多的构造函数，例如DrawioEditor或mxGraph实例数翻倍，基本锁定vscode-drawio - 不要只看总内存大小，要盯住
Retained Size和重复出现的闭包引用链
禁用插件前先查 Extension Host 日志
有些插件不显性占资源，但高频打日志拖慢主线程（典型如旧版 GitLens 的 commit graph 自动加载）。
- 打开
Output面板 → 下拉选择Log (Extension Host) - 搜索关键词：
WARN、ERR、slow、took（如activation took 1243ms） - 留意日志时间戳是否密集（一秒内刷出 10+ 条），这代表插件在事件循环里反复调度
- 对高频输出日志的插件，优先检查其设置项，例如关闭
gitlens.graph.enabled或prettier.requireConfig
真正关键的不是“看到多少数字”，而是把 Process Explorer 的数值变化、Extension Host 日志里的耗时记录、以及 Memory 快照中的对象增长三者对齐——漏掉任一环，都可能把 typescript-language-server 的冷启动延迟误判成某个 UI 插件的问题。
