VSCode不提供插件CPU使用率曲线，Process Explorer仅显示Extension Host进程级瞬时采样值，无法归因到具体插件函数；必须用Developer: Start/Stop Extension Host Profile生成.cpuprofile，再通过Chrome DevTools分析V8采样调用栈，重点关注Self Time定位activate()等生命周期方法中的同步阻塞热点。
VSCode 插件调试本身不提供 CPU 使用率曲线，只能通过 Extension Host 进程采样值间接判断——真正要监控插件代码的 CPU 消耗，必须用 Developer: Start/Stop Extension Host Profile 生成火焰图，再用 Chrome DevTools 分析。
为什么 Process Explorer 里的 CPU% 不代表你的插件逻辑
Process Explorer 显示的是整个 Extension Host 进程的瞬时 CPU 占比，不是你插件里某个函数的执行时间。它每 1–2 秒轮询一次系统 getrusage 或 GetProcessTimes，结果是进程级估算，无法区分 ms-python.python 和 esbenp.prettier-vscode 各自贡献了多少。
- 如果你插件只在保存时触发一次格式化，Process Explorer 可能根本抓不到峰值
- 多个插件共用一个 Extension Host 进程时，高 CPU% 是叠加结果，无法归因
- 该数值不含 Node.js 底层调用（如 fs.readSync、worker_threads），容易低估真实开销
用 Developer: Start/Stop Extension Host Profile 抓真实调用栈
这是唯一能定位到你插件 JS 代码哪一行吃 CPU 的方式。它基于 V8 CPU Profiler，记录的是 JS 执行帧的精确耗时（单位：毫秒），不是系统采样。
- 先在命令面板执行
Developer: Start Extension Host Profile - 立刻复现问题操作（比如打开一个 .ts 文件、触发补全、保存文件）
- 几秒后执行
Developer: Stop Extension Host Profile，VSCode 自动打开火焰图页面 - 在 Chrome DevTools 中打开导出的
.cpuprofile，重点看 “Self Time” 列——值高的函数就是你插件里没优化的热点
注意：activate()、provideCompletionItems()、onDidChangeTextDocument() 这些生命周期方法如果同步做了大文件读取或正则匹配，会直接出现在顶部长条里。
常见陷阱：profile 没抓到数据 or 火焰图全是 anonymous
Profile 失效通常不是工具问题，而是启动时机或环境不对：
- 没在插件激活后立即 start —— profile 必须在插件已加载且事件监听器注册完毕后才开始，否则捕获不到回调执行
- 用了
setTimeout或setInterval延迟执行逻辑，但 profile 在定时器触发前就 stop 了 - 插件代码被 webpack 打包后未保留 source map，火焰图里函数名变成
anonymous或webpack:///./src/…；需在webpack.config.js中配devtool: 'source-map'并确保输出路径正确 - VSCode 启用了
"extensions.experimental.affinity": { "your-publisher.your-ext": 1 }，导致插件运行在独立进程，而 profile 默认只监控主 Extension Host
配合 code --status 定位真实子进程 PID
当 profile 显示某段代码耗时高，但你不确定是不是被其他插件干扰，就得跳出去确认进程归属：
- 终端执行
code --status，找到 CPU% 高的行，记下 PID - 用
ps -p [PID] -o args=（macOS/Linux）或任务管理器“详细信息”页右键 → “打开文件位置”，确认命令是否含你插件路径（如/home/user/.vscode/extensions/your-publisher.your-ext-1.0.0/out/extension.js） - 如果命令里是
tsserver或pyright，说明高 CPU 实际来自语言服务，不是你插件——别白调 profile - 若 PID 对应进程已退出，
code --status会显示(gone)，此时 profile 数据可能已失效
真实插件性能问题往往藏在「你以为它在跑，其实早被 kill」和「你以为它在后台，其实卡在主线程同步阻塞」之间——profile 和 code --status 必须交叉验证，缺一不可。
