应直接查看 extensionHost 进程内存，而非任务管理器显示值；通过 Developer: Open Process Explorer 定位高内存插件，空闲时 150–300 MB 正常，持续超 500 MB 即可能存在泄漏。
直接看 extensionHost 进程内存，别信任务管理器
Windows 任务管理器或 macOS 活动监视器里显示的 Code Helper 或 Code.exe 内存值严重失真——它只统计单个渲染进程，而 VSCode 实际把插件、Webview、终端全拆成独立子进程。真正该盯的是整个进程树里的 extensionHost 占用。
操作路径：按 Ctrl+Shift+P（Win/Linux）或 Cmd+Shift+P（Mac），输入并运行 Developer: Open Process Explorer。展开 extensionHost 节点，按 Memory 列降序排列，一眼就能看到哪个插件子进程吃掉了 400MB+。
- 空闲时
extensionHost稳定在 150–300 MB 属正常；持续 >500 MB 且不回落，基本就是泄漏 - 某插件（如
esbenp.prettier-vscode）格式化大 JSON 时瞬时飙到 400 MB 是合理的，但 30 秒后仍 >200 MB 就得查 - 禁用插件后必须运行
Developer: Restart Extension Host，否则内存不会释放
代码里嵌入监控，要精确就别靠外部工具
系统级工具只能告诉你“VSCode 吃了多少”，但没法回答“我写的这段 Python/C++ 到底占了多少内存”。这时候就得在代码里埋点，用语言原生 API 获取真实资源消耗。
Python 示例（Linux/macOS 有效）：
import resource
import time
<p>start_time = time.time()</p><h1>你的业务逻辑</h1><p>end_time = time.time()</p><p>mem_kb = resource.getrusage(resource.RUSAGE_SELF).ru_maxrss
print(f"CPU 时间: {end_time - start_time:.4f}s, 内存峰值: {mem_kb} KB")-
ru_maxrss返回的是最大驻留集大小（KB），比psutil.Process().memory_info().rss更贴近 OS 实际分配 - Windows 上
resource不可用，得换psutil，但要注意它返回的是当前快照，不是峰值 - C++ 可用
getrusage(RUSAGE_SELF, &usage)，和 Python 的resource对应，但需注意单位（Linux 是 KB，macOS 是字节）
用 Code Runner 扩展实时看，但得配对启用
Code Runner 插件本身不显示资源，但配合配置能输出执行耗时和基础内存变化——前提是开启它的资源监控开关，且底层命令支持 time 或 Measure-Command。
- 在
settings.json中加这两行："code-runner.showExecutionMessage": true, "code-runner.resourceMonitoring": true
- 它实际调用的是 shell 的
time（Linux/macOS）或 PowerShell 的Measure-Command（Windows），所以只对终端可执行命令有效，对 Python 脚本这种解释型语言，显示的“内存”其实是进程启动开销，不是脚本本身 - 如果想看 Python 脚本真实内存，还是得用前面说的
resource或tracemalloc，Code Runner只适合快速对比不同脚本的相对耗时
别被 “当前工作区内存” 概念骗了
VSCode 没有“当前工作区专属内存”这个东西。所有打开的工作区共享同一个 extensionHost 和多个 renderer 进程。你看到的内存数字是整个实例的聚合值，但可以通过进程树反向聚焦。
- 在
Developer: Open Process Explorer里，留意Workspace列有路径的进程，比如/path/to/my-project或ms-python.python (python)，这些才是和你当前编辑文件强相关的 - 开了多根工作区（multi-root workspace）？每个根目录下的插件可能启动独立子进程，Memory 值高 + 路径匹配，就是那个根目录的“主力消耗者”
-
files.watcherExclude这类配置只影响文件监视器（通常只占 20–50 MB），不是内存大户，别指望靠它解决卡顿
