VSCode不提供当前工作区专属内存或代码运行时CPU占用指标，高内存卡顿90%源于extensionHost或renderer进程中的插件驻留RSS内存；通过Developer: Open Process Explorer可定位具体插件，按Memory列排序并结合Workspace路径识别关联工作区的高耗插件，禁用后需重启extensionHost才生效。
VSCode 本身不提供“当前工作区专属内存”或“代码运行时 CPU 占用”这类聚合指标——你看到的高内存、卡顿，90% 是 extensionHost 或 renderer 进程里某个插件在驻留 RSS 内存，而不是编辑器坏了。直接用内置 Developer: Open Process Explorer 就能定位到具体是哪个插件占了 400MB 还不释放。
怎么看 extensionHost 里哪个插件真正在吃内存
extensionHost 进程是所有插件的运行沙箱，它下面每个子项对应一个「已加载并正在运行」的插件（不是“已安装”）。关键看 Memory 列的 RSS 值（单位 MB），这才是真实物理内存占用：
- 按
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS），输入并运行Developer: Open Process Explorer - 展开
extensionHost节点，点击Memory列标题排序，前几名就是嫌疑对象 - 重点看
Workspace列：带具体路径（如/home/user/my-project）的，基本可锁定为当前工作区关联；没显示路径的，右键 →Reveal in Explorer查它加载的是哪个package.json - 瞬时峰值（比如
esbenp.prettier-vscode格式化大 JSON 飙到 500 MB）正常；空闲时仍稳定在 300 MB+，大概率泄漏
禁用插件后内存不降？因为你没重启 extensionHost
右键插件选 Disable (For All Folders) 只是标记状态，旧子进程还挂着，Memory 值一毛不动：
- 禁用可疑插件后，必须在命令面板运行
Developer: Restart Extension Host，让进程树重建 - 更彻底验证：关闭当前窗口，终端执行
code --disable-extensions /path/to/project重开——如果卡顿消失，100% 是插件问题 - 某些插件（如
GitHub.copilot、ms-vscode-remote.remote-ssh）会注册全局监听器，禁用后可能残留子进程，需手动ps aux | grep -i "copilot\|remote"+kill -9 [PID]
为什么 renderer 进程内存有时比 extensionHost 还高
这不是插件写得差，而是 Electron 渲染进程本身的开销——每个 Webview 都是独立 Chromium 实例：
- 如果你开了 Jupyter Notebook、Storybook 预览、Quokka、Swagger Viewer，就很容易在
Developer: Open Process Explorer中看到类型为renderer且Title含关键词的进程内存飙升 - macOS 上若
Shared Memory异常高（>800 MB），大概率是某插件用了SharedWorker却没调用terminate() - 这类高内存无法靠禁用插件解决，只能关掉对应 Webview 标签页，或改用 CLI 方案（比如用
storybook dev替代内置预览）
别被 files.watcherExclude 欺骗，它只管小头
这个配置只影响文件监视器（watcher 进程），通常只占 20–50 MB，不是内存大户：
- 真正吃内存的是 LSP 服务（如
rust-analyzer、pyright）、GitLens 全仓库缓存、ESLintonType模式等 -
files.watcherExclude必须写成"**/node_modules/**": true，写成*node_modules*或/node_modules/无效 - 改完必须关闭并重新打开工作区，仅保存配置不生效；Linux 用户若仍卡顿，检查
cat /proc/sys/fs/inotify/max_user_watches，低于 524288 就要调高
最易被忽略的点：RSS 内存值是实时快照，不是趋势图；空闲驻留 >300 MB 才算异常，但很多人盯着瞬时峰值反复禁用重启，反而错过真正泄漏源。
