应使用Developer: Open Process Explorer查看extensionHost下各插件RSS内存，重点关注关闭所有文件后仍稳定高于300MB且不回落的插件，如esbenp.prettier-vscode空载维持420MB即为泄漏源。
怎么看 Extension Host 进程是否真在泄漏内存
别只盯着任务管理器里模糊的 “Code Helper” 数值——它混着渲染进程、GPU 进程，根本看不出哪个插件在偷偷吃内存。真实泄漏表现是：关闭所有编辑器标签页后，extensionHost 进程 RSS 内存不回落，甚至持续爬升。
直接用 VSCode 自带工具验证：
- 按
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS），执行Developer: Open Process Explorer - 展开
extensionHost节点，按Memory列排序 - 重点关注“空闲驻留值”：比如
esbenp.prettier-vscode关掉所有文件后还稳在 420MB，基本就是泄漏源
为什么点击“运行”会卡住几秒？常见插件行为坑点
不是所有高内存都拖慢点击响应——真正卡“运行”按钮的，往往是那些在 onDidChangeTextDocument 或 onDidSaveTextDocument 里干重活的插件。它们没节流、没防抖，一敲字就触发 AST 全量解析，等你点“运行”时，主线程正被堵在上一个格式化任务里。
典型高危模式：
-
vscode.workspace.findFiles('**/*.ts', '**/node_modules/**')同步遍历大目录，阻塞整个 Extension Host - 监听
workspace.onDidOpenTextDocument却没配对清理WeakMap或事件监听器，导致旧文档对象无法 GC - Webview 消息回调里闭包捕获了整个
context，而webview.onDidReceiveMessage没配对调用offDidReceiveMessage
怎么快速定位到具体是哪个插件拖慢“运行”
禁用插件后不重启 extensionHost，内存和响应延迟根本不会释放——这是很多人忽略的关键动作。
实操步骤：
- 在命令面板执行
Developer: Show Running Extensions，看哪些扩展标着 “Running” 且 CPU 估算偏高 - 右键疑似插件 →
Disable (For All Folders)，然后必须立刻执行Developer: Restart Extension Host - 如果“运行”响应明显变快，再逐个启用插件，复现卡顿点
- 更彻底验证：终端执行
code --disable-extensions --file-watchers=false直接启动干净环境，对比响应时间
泄漏插件修复后仍卡？检查 Webview 渲染器堆限制
很多 AI 辅助类插件（如 github.copilot、ms-toolsai.jupyter）把重逻辑扔进 Webview，但默认 V8 堆上限只有 700MB。一旦缓存或消息队列堆积，GC 触发不及时，就会拖慢整个 UI 响应链。
调整方法：
- 启动时加参数：
code --max-old-space-size=2048（提升 Extension Host 主进程上限） - 若插件自建 Webview，在其 HTML 中插入：
<script>v8.setFlagsFromString('--max_old_space_size=1024');</script> - 注意：该 flag 必须在 Webview 初始化早期执行，晚于
document.readyState === 'complete'就无效
真正难处理的是那种 Webview 和 Extension Host 双端都持有对方引用的循环依赖——堆快照里能看到大量 Closure 和 Detached DOM tree 并存，这时候光调参数没用，得翻插件源码找 dispose() 是否漏掉了 webview.dispose() 或 removeEventListener。
