如何在 VSCode 中运行并监控内存使用情况

VSCode内存占用排查：从入门到避坑

很多人觉得VSCode越来越吃内存，打开任务管理器一看，Code Helper占了500MB，心里就开始嘀咕是不是出问题了。但坦白说，你盯着任务管理器看到的那个数字，其实并不靠谱——它只反映了单个渲染进程的情况，而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方面，推荐用内置的resource模块进行精准测量：

import resource
import time

start_time = time.time()
# 你的业务逻辑
end_time = time.time()

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的当前快照更贴近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或PowerShell的Measure-Command，只对终端可执行命令有效。对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），不是内存大户，指望靠它解决卡顿基本是白费力气。

一句话总结：排查内存问题，先找对工具，再看准数据，最后才能采取有效行动。