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