用code --status诊断启动慢，重点关注Startup总耗时、activationTime＞500且isActivated:true的扩展及extensionHost总耗时；activationTime为-1表示懒加载未触发，不可忽略；多扩展合计超1200ms必卡顿。
VSCode卡顿、启动慢、内存飙升，问题大概率出在扩展上。直接查 Extension Host 进程和具体扩展的激活行为，比猜更可靠。
怎么看哪个扩展拖慢启动？用 code --status
这是最轻量、最权威的冷启动诊断方式，不依赖UI，输出即真相。
-
code --status必须在终端中运行（macOS 稳定版有时不完整，建议用code-insiders --status） - 重点关注三列：
Startup（总启动耗时）、各扩展的activationTime、末尾的extensionHost启动总耗时 -
activationTime > 500且isActivated: true的扩展是高危对象；activationTime为-1表示尚未激活（懒加载），不能忽略 - 多个扩展
activationTime合计超1200ms，用户必然感知卡顿
怎么实时看扩展 CPU 和内存占用？开 Developer: Open Process Explorer
它不是“任务管理器翻版”，而是能精准映射到 VS Code 内部进程结构的视图。
- 命令面板输入
Developer: Open Process Explorer即可打开，无需重启 - 关注
Extension Host进程的CPU和Memory列，数值持续 >80% 就值得怀疑 - Windows 用户右键进程 → Properties → Image Path，路径末尾常含扩展 ID（如
ms-python.python） - macOS/Linux 可配合
ps aux --forest | grep extensionHost辅助定位子进程归属
怎么确认是不是某个扩展导致内存泄漏？拍堆快照对比
仅看内存数字没用，得看“谁占了、为什么没释放”。
- 按
F12打开开发者工具 → 切到Memory面板 - 点
Take heap snapshot拍第一张；执行可疑操作（如反复打开/关闭 LeetCode 题目）；再拍第二张 - 对比两次快照，筛选
Retained Size增长明显、且类型为Closure或带扩展名（如LeetCodeChannel）的对象 - 特别注意未解绑的
vscode.workspace.onDidChangeConfiguration监听器，这是 vscode-leetcode、GitLens 等插件的常见泄漏点
怎么快速验证某个扩展是否真有问题？禁用 + 重启 + 对比
别信“看起来正常”，要测真实负载变化。
- 禁用后必须执行
Developer: Reload Window（不是普通刷新），否则Extension Host进程可能仍驻留旧逻辑 - 观察
Developer: Open Process Explorer中Extension Host的内存回落幅度——下降 >30MB 才算显著改善 - 对 vscode-leetcode 这类高频交互插件，还要额外检查
Output面板 → 选LeetCode通道，看是否有重复Fetching problem...或超时日志 - 禁用语言服务器（如
ms-python.python）后若响应变快，说明问题不在插件本身，而在其后台服务（如 Pylance）的资源调度
真正难排查的从来不是“哪个扩展在跑”，而是“它在什么条件下悄悄吃资源”——比如只在打开 .py 文件夹时激活、只在 Git 提交图渲染时轮询 API。所以别只看单次快照或静态列表，要结合场景复现、进程路径溯源、输出日志交叉验证。这些步骤看似琐碎，但跳过任意一环，都可能把问题归给“VS Code 本身”。
