VSCode性能监控需通过命令行参数或内置命令实现，如--prof-startup抓启动卡顿、--disable-gpu排除GPU干扰、Developer: Open Process Explorer查看扩展资源占用，配合Performance Impact定位用户感知卡顿根源。
VSCode 本身不提供“一键开启性能监控”的配置项，所有有效监控都依赖命令行启动参数或内置开发命令，跳过这步直接在设置里找选项，永远找不到真实数据。
用 code --prof-startup 抓启动卡顿根源
编辑器启动慢？不是看“花了多久”，而是看“哪一步拖得最久”。--prof-startup 会记录从进程创建到 UI 渲染完成的完整调用链，生成可分析的跟踪日志。
- 必须关闭所有 VSCode 实例后再执行，否则参数不生效
- 搭配
--trace-renderer可同时捕获渲染线程行为，定位白屏或闪烁问题 - 日志默认存放在
$HOME/.config/Code/logs/（Linux/macOS）或%APPDATA%\Code\logs\（Windows），文件名含时间戳和进程 ID - 别指望 VSCode 自己解析——用 Chrome 浏览器打开
chrome://tracing，加载生成的.json文件才能看清各阶段耗时
用 code --disable-gpu 排除显卡驱动干扰
界面卡顿、滚动掉帧、高 CPU 占用却没明显扩展负载？大概率是 GPU 硬件加速与当前显卡驱动不兼容，尤其常见于远程桌面、WSL2 图形转发、老旧集成显卡环境。
-
--disable-gpu强制走软件渲染，UI 响应变稳但动画可能略钝，这是可接受的诊断手段，不是最终方案 - 不要和
--no-sandbox混用，后者有安全风险，仅当确认是沙盒机制冲突时才临时启用 - 验证是否生效：启动后打开开发者工具（
Ctrl+Shift+I），在 Console 输入process.versions，检查chrome字段版本，若显示正常且无 GPU 相关报错，说明已切换成功
用 Developer: Open Process Explorer 实时盯住扩展宿主
这不是“配置参数”，但它是你每天该打开三次的性能仪表盘。它不依赖任何插件，原生显示每个扩展的真实资源消耗。
- 按
Ctrl+Shift+P输入并执行该命令，重点关注Extension Host下展开的子项，比如ms-python.python或esbenp.prettier-vscode - CPU 长期 >8% 或内存持续上涨（非瞬时峰值）就是可疑对象；右键禁用后必须重启 VSCode，否则旧进程仍驻留
- 配合
Developer: Toggle Performance Impact使用：状态栏出现 ⚡ 后点开，能看到“Save took 320ms — caused by extension 'xyz'”，这才是用户感知层面的卡顿来源
真正难的不是启动参数本身，而是区分“编辑器卡”和“扩展卡”——前者靠 --disable-gpu 或 --prof-startup 定位，后者靠 Process Explorer 和 Performance Impact 联动验证。参数只是扳手，扳不动的时候，得知道往哪颗螺丝上使力。
