VSCode内置Process Explorer可查看各进程内存和CPU占用，按Ctrl+Shift+P输入“Developer: Open Process Explorer”打开；它不提供系统级监控，需配合外部工具如Windows的perfmon、macOS的Activity Monitor或Linux的htop使用。
VSCode 自带的性能监视器怎么打开
VSCode 本身不提供系统级资源监控（如 CPU、内存占用率），但内置了一个轻量级的 Developer: Toggle Developer Tools 和 Developer: Open Process Explorer，能帮你快速定位是 VSCode 自身哪个进程在吃资源。
按 Ctrl+Shift+P（Windows/Linux）或 Cmd+Shift+P（macOS），输入并选择 Developer: Open Process Explorer —— 这个视图会列出所有渲染进程、扩展主机、GPU 进程及其内存占用（MB）、CPU 占用（%）、工作区路径。注意：这里的 CPU % 是相对当前采样周期的估算值，并非系统级实时数据。
- 主窗口进程（Main）异常高内存？可能是某扩展持续泄漏 DOM 节点
- Extension Host 进程 CPU 长期 >80%？大概率是某个扩展在后台轮询或未正确 dispose 事件监听器
- 多个同名扩展进程？说明该扩展启用了多工作区实例，可能重复加载
想看真实系统资源，得靠插件 + 系统工具配合
VSCode 插件市场里没有真正“监控系统”的插件——因为沙箱限制，插件无法直接读取 /proc（Linux）或 WMI（Windows）。靠谱做法是：用外部工具采集，再通过终端或状态栏插件间接展示。
推荐组合：
- Windows：用
tasklist /fi "imagename eq code.exe"查 VSCode 主进程 PID，再用perfmon或Windows Performance Analyzer挂载分析 - macOS：终端运行
top -pid $(pgrep -f "Code Helper")或用Activity Monitor搜索 “Code” 进程组 - Linux：
htop中按F4过滤code，或用ps aux --sort=-%mem | grep code
如果非要集成进 VSCode 界面，可装 systemd-monitor（仅 Linux）或 CPU Usage（跨平台，但实际调用的是 Node.js 的 os.cpus() 和 process.memoryUsage()，只反映本进程）——别被名字误导，它不监控系统整体。
哪些扩展最容易引发性能问题
不是所有扩展都平等。以下几类扩展在大型工作区中极易拖慢响应、抬高内存：
-
eslint+prettier同时启用且配置了onSave格式化：每次保存触发两轮 AST 解析，尤其对node_modules未忽略时 -
GitLens开启了git.statusBar.enabled和git.blame.lineEnabled：每行代码旁实时计算 blame，文件超 2000 行就明显卡顿 -
Remote-SSH连接后又装了本地版Python扩展：VSCode 会同时激活本地和远程 Python 解释器，导致两个pyls进程争抢资源 - 任何使用
fs.watch但未限定ignored目录的文件监听扩展（比如旧版Auto Rename Tag）：在含大量构建产物的目录里会触发海量事件
排查卡顿最有效的三步操作
别一上来就重装 VSCode。先做这三件事：
- 启动时加
--disable-extensions参数：code --disable-extensions，确认是否由扩展引起 - 用
Developer: Start Extension Bisect二分法禁用一半扩展，重启测试；反复直到定位到具体扩展 - 检查
settings.json里有没有全局启用的 heavyweight 配置，例如："files.watcherExclude": {}留空、"editor.quickSuggestionsDelay": 0、"emeraldwalk.runonsave"类自动执行扩展未设条件
真正的瓶颈往往不在“用了什么”，而在“什么时候用”和“对谁用”。比如 typescript.preferences.includePackageJsonAutoImports 设为 "auto" 时，只要打开任意 JSON 文件，TS 服务就会尝试解析整个 node_modules —— 这种隐式行为比明面上的插件更难察觉。
