VSCode可通过帮助→开发者工具→性能或命令面板打开Performance面板查看内存占用，需点击Start profiling录制后才能显示Memory时间线，区分Renderer与Extension Host进程，并用Process Explorer定位高内存插件。
VSCode 自带的性能面板怎么看内存占用
VSCode 内置了实时性能监控，不需要装插件就能看到当前窗口的内存使用情况。关键入口在菜单栏：帮助 → 开发者工具 → 性能，或者直接按 Ctrl+Shift+P（Windows/Linux）或 Cmd+Shift+P（macOS），输入 Developer: Toggle Developer Tools 打开控制台后，切到 Performance 标签页。
常见错误现象：点开后一片空白，或只显示“Recording stopped”——这是因为默认没开启录制。必须先点右上角的圆点按钮 Start profiling，操作几秒后再点 Stop profiling，才能生成可分析的火焰图和内存时间线。
- 内存曲线在底部
Memory面板中，纵轴是 MB，横轴是时间，高峰处对应你刚执行的大动作（比如打开大文件、运行测试） - 注意区分
Renderer（主编辑器界面进程）和Extension Host（插件运行环境）的内存，后者暴涨往往说明某个插件泄漏 - macOS 上如果看到
Shared Memory异常高，大概率是某扩展用了 Electron 的sharedWorker但没清理引用
用 VSCode 进程管理器定位高内存插件
VSCode 的进程管理器比系统任务管理器更精准，它能按进程类型拆分资源，尤其适合揪出吃内存的扩展。
打开方式：按 Ctrl+Shift+P，输入并运行 Developer: Open Process Explorer。你会看到树状结构，根节点是主进程，子节点包括 shared-process、extensionHost、多个 renderer 等。
-
extensionHost下列出的所有子项，就是已启用的扩展；旁边数字是其 RSS 内存占用（MB），排序后一眼可见谁最贪 - 禁用可疑扩展后，别忘了重启
extensionHost：在命令面板运行Developer: Restart Extension Host，否则内存不会立即释放 - 某些扩展（如
esbenp.prettier-vscode）在格式化超长 JSON 时会临时飙到 500MB+，属正常行为；但若空闲时仍稳定占 300MB+，就该怀疑泄漏
命令行查 VSCode 底层进程真实内存（绕过 UI 限制）
VSCode 的 UI 面板只显示渲染进程视角，有时会低估。真正想看 OS 层面的内存分配，得直接查进程。
在终端里运行对应命令：
ps -o pid,rss,comm -p $(pgrep -f "Code Helper") | awk '{sum += $2} END {print "Total RSS (KB): " sum}'
注意点：
-
Code Helper是 macOS/Linux 下的通用进程名；Windows 要换成Code.exe，且需用tasklist /fi "imagename eq Code.exe" /fo list - RSS（Resident Set Size）比 VSCode 面板显示的 “memory” 更接近物理内存实际占用，尤其对长期运行的扩展更准
- 如果发现多个
Code Helper进程 RSS 总和远超面板数值（比如面板报 800MB，命令行加起来 1.7GB），说明有插件启用了独立 worker 且未被面板统计
为什么关掉一个插件，内存没降？这些细节容易被忽略
VSCode 的内存释放不是即时的，尤其涉及 WebAssembly、大型缓存或未正确 dispose 的事件监听器时。
- 重启
extensionHost后仍不降？试试完全退出 VSCode（包括托盘图标），再重进——有些扩展的 shared memory 在进程级残留 - 用
Developer: Toggle Developer Tools查Console面板，过滤WARNING，留意类似Extension 'xxx' took Xms to activate或Leak detected的提示 - 某些语言服务器（如
rust-analyzer）会在后台持续维护索引，即使关闭对应文件，内存也不会立刻归零；这是设计使然，不是 bug
真正的瓶颈往往不在“哪个插件开了”，而在“哪个插件在后台不断累积状态却没清理”。盯住 extensionHost 的 RSS 曲线是否随时间缓慢爬升，比单看瞬时值更有意义。
