Developer: Open Process Explorer是VSCode唯一直观查看各插件真实RSS内存和CPU占用的原生命令，需重点关注Memory（驻留内存是否>300MB）、CPU（连续10秒是否>25%）及extensionHost下子项（如esbenp.prettier-vscode），禁用后须执行Developer: Restart Extension Host才能释放内存。
Developer: Open Process Explorer 看什么
这是 VSCode 唯一真正能告诉你“谁在吃资源”的原生命令，不是任务管理器里那个模糊的 Code Helper 进程，而是精确到每个扩展的实时 RSS 内存和 CPU 占用。
执行后重点关注三列：
-
Memory：单位 MB，看驻留内存是否持续不降（比如关掉所有文件后还 >300MB） -
CPU：不是峰值，是连续 10 秒内是否稳定 >25% —— 某些插件只在保存时爆发，静态值会漏判 -
Extension Host下的子项：每个条目对应一个已启用扩展，名称格式如esbenp.prettier-vscode或ms-python.python
右键可直接禁用，但注意：禁用 ≠ 释放内存，旧进程还在跑，必须重启窗口或执行 Developer: Restart Extension Host 才生效。
为什么 CPU 高 ≠ 卡顿？要看 Performance Impact
有些插件 CPU 占用不高，但会让你打字卡顿 200ms —— 因为它在 onType 回调里做了同步阻塞操作（比如没加 await 就读大文件、跑正则匹配）。
运行 Developer: Toggle Performance Impact，状态栏会出现 ⚡ 图标，点开就能看到最近一次操作（输入、保存、补全）的延迟分解。例如：
Typing took 142ms — caused by extension 'aaron-bond.better-comments'
这比看 CPU 百分比更能反映真实卡顿体验。如果某个插件频繁出现在这里，说明它没做异步处理，主线程被它锁死了。
Extension Host Profile 火焰图怎么导出和看
当你锁定某个可疑扩展，想确认是哪段代码拖慢时，用 Developer: Start Extension Host Profile 开始采样，操作复现卡顿场景，再用 Developer: Stop Extension Host Profile 导出 .cpuprofile 文件。
这个文件不能直接在 VSCode 里打开，必须用 Chrome DevTools：
- 打开
chrome://devtools→Performance标签页 → 右上角⋯→Load profile - 火焰图里重点找长条函数（比如
provideCompletionItems、onDidChangeTextDocument），尤其是调用栈深、耗时占比高的节点 - 注意：它只记录 JS 执行，不包含底层 Node.js C++ 调用；若怀疑是语言服务器问题（如 TypeScript Server），得改用
launch.json调试主进程
files.watcherExclude 不配等于白查
很多卡顿根本不是插件问题，而是 VSCode 在疯狂监听不该监听的目录。比如没配 "files.watcherExclude"，它就会对 node_modules、dist、.git 下每一层子目录轮询变更，CPU 直接拉满。
在 .vscode/settings.json 中加上：
"files.watcherExclude": {
"**/node_modules/**": true,
"**/dist/**": true,
"**/.git/**": true,
"**/build/**": true
}
别信某些教程说“VSCode 会自动排除”，它不会 —— 尤其在 WSL 或远程开发时，符号链接 + 大量小文件会让 watcher 彻底失控。配完立刻生效，不用重启。
真正容易被忽略的是：启动慢往往发生在扩展激活前，而 Developer: Startup Performance 显示的 Activate Time 超过 500ms 的扩展，大概率在 activate() 里做了同步 I/O 或未缓存的正则初始化，这种问题火焰图也抓不到，只能靠启动分析定位。
