VSCode无当前工作区专属内存统计，需用Developer: Open Process Explorer展开extensionHost节点，按Memory列排序查看各插件RSS内存，结合Workspace路径与插件名定位归属，瞬时峰值正常但空闲驻留超300MB即可疑，禁用后须重启Extension Host才能释放内存。
VSCode 没有“当前工作区专属内存”这个数值，所有进程共享资源；要定位真实消耗源，必须用 Developer: Open Process Explorer 查 extensionHost 和 renderer 子进程的 RSS 内存，结合路径和插件名判断归属。
怎么看 extensionHost 里哪个插件在吃内存
VSCode 的 extensionHost 进程是插件运行沙箱，它下面每个子项对应一个已激活插件——不是“已安装”，而是“已加载并正在运行”。Memory 列显示的是该插件子进程的 RSS（实际物理内存占用，单位 MB），这才是你该盯的数字。
- 按
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS），输入并运行Developer: Open Process Explorer - 展开
extensionHost节点，点击 “Memory” 列标题排序，前几名就是嫌疑对象 - 注意看 “Workspace” 列：带具体路径（如
/home/user/project）的，基本可锁定为当前工作区关联；没显示路径的，右键 →Reveal in Explorer看它加载了哪个package.json或node_modules - 瞬时峰值（比如
esbenp.prettier-vscode格式化大 JSON 飙到 500 MB）正常；但空闲时仍稳定在 300 MB+，大概率是泄漏
renderer 进程内存高 ≠ 插件问题，但得会分辨
如果你的工作区开了 Jupyter Notebook、Storybook 预览、或者用了大量 Webview 的插件（如 Quokka、Swagger Viewer），renderer 进程的 Memory 可能比 extensionHost 还高。这不是插件写得差，而是 Electron 渲染进程本身的开销——每个 Webview 都是独立的 Chromium 实例。
- 在
Developer: Open Process Explorer中，找类型为renderer且 “Title” 或 “Workspace” 列含你项目名或 Webview 关键词的进程 - macOS 上若看到
Shared Memory异常高（>800 MB），大概率是某插件用了SharedWorker却没调用terminate() - 这类高内存无法靠禁用插件解决，只能关掉对应 Webview 标签页，或改用非 Webview 替代方案（比如用 CLI 启动 Storybook 而非内置预览）
禁用插件后内存不降？因为你没重启 extensionHost
右键插件选 Disable (For All Folders) 只是标记状态，旧的子进程还挂着，RSS 一毛不动。真正释放内存需要让 extensionHost 重建进程树。
- 禁用可疑插件后，必须在命令面板运行
Developer: Restart Extension Host（别信“重载窗口”，它不一定重启 extensionHost） - 更彻底验证：终端执行
code --disable-extensions /path/to/your/project，如果卡顿消失，100% 是插件问题 - 某些插件（如
GitHub.copilot、ms-vscode-remote.remote-ssh）注册了全局监听器，即使禁用也可能残留子进程，需手动查ps aux | grep -i "copilot\|remote"并kill -9 [PID]
真正的难点不在“怎么打开进程管理器”，而在于区分瞬时分配与持续驻留、识别 Webview 渲染开销与插件泄漏、以及理解禁用 ≠ 停止——这些细节漏掉一个，排查就变成碰运气。
