code --prof-startup 可录启动性能，但需配合 --trace-renderer 才完整，且必须先彻底关闭所有 VSCode 实例；日志存于 logs 目录，需用 Chrome DevTools 手动分析，不直接显示火焰图。
直接用 code --prof-startup 启动就能录启动性能
VSCode 没有“性能分析模式”开关，但 code --prof-startup 是最接近的原生命令——它会在启动瞬间开始采样主线程和渲染进程，生成可导入 Chrome DevTools 分析的 .cpuprofile 文件。这个参数必须配合 --trace-renderer 才能捕获完整渲染路径，否则只录到主进程部分。
- 必须先彻底关闭所有 VSCode 实例（包括托盘后台进程），否则新参数不生效
- 日志默认存放在
$HOME/.config/Code/logs/（Linux/macOS）或%APPDATA%\Code\logs\（Windows）下，按日期建子目录 - 如果想同时禁用扩展干扰，加
--disable-extensions；若怀疑 GPU 渲染问题，再叠加--disable-gpu - 别指望命令行直接弹出火焰图——它只生成原始数据，得手动用 Chrome 打开
chrome://tracing或 DevTools 的 Performance 面板加载 .trace 文件
code --enable-profiler-ui 会显示实时 FPS 计数器
这个参数不记录数据，只在编辑器右上角渲染一个半透明的 FPS 小窗（类似游戏 HUD），数值来自 Chromium 的 Compositor 线程。它对判断界面卡顿是否由帧率崩塌引起很直观，但无法定位具体函数。
- 启动后需手动打开开发者工具（
Ctrl+Shift+I），Performance 面板才可用；仅靠 FPS 显示器看不出 JS 执行瓶颈 - 如果小窗显示
0 FPS或长期低于 30，大概率是 GPU 进程挂了或显卡驱动异常，此时--disable-gpu比调优代码更有效 - 该参数与
--prof-startup不冲突，可共用，但--enable-profiler-ui对 CPU 分析无实质帮助
组合命令才是日常排查主力
单个参数解决不了多数真实问题。比如启动慢，往往是扩展 + GPU + 渲染三者叠加导致，必须组合使用才能快速收窄范围。
- 典型组合：
code --disable-gpu --disable-extensions --prof-startup --trace-renderer - 若仍卡顿，说明是 VSCode 主程序或 Electron 底层问题；若恢复正常，再逐个启用扩展定位元凶
-
--no-sandbox仅在沙盒机制导致进程崩溃时临时启用（如某些企业 Docker 环境），日常禁用——它绕过 Chromium 安全隔离，可能被杀毒软件拦截 - Windows 用户注意：PowerShell 里执行带多个短横线的参数容易报错，建议改用 CMD 或在 PowerShell 中给整个命令加引号：
code "--disable-gpu --prof-startup"
别漏掉 --status 查扩展激活耗时
这个参数不启动编辑器，只输出冷启动各阶段耗时统计，特别适合查“为什么第一次打开要等 8 秒”。它会列出每个扩展的 Activate Time，超过 500ms 的基本就是性能拖累源。
- 执行
code --status后，重点看 “Extension Activation Times” 表格末尾的数字，不是看总时间 - 如果某扩展显示
activate: 2417 ms，说明它在初始化时做了同步 I/O 或正则爆炸，不是靠禁用就能解决，得去 GitHub 看它 issue 区有没有同类反馈 - 这个命令输出是纯文本，可重定向保存：
code --status > startup.log，方便对比不同环境下的差异
真正卡住人的，从来不是记不住参数，而是没意识到 --prof-startup 生成的日志必须手动加载分析、--status 的输出需要人工盯住具体毫秒数、以及 --disable-extensions 后必须重启才能释放旧 Extension Host 进程的内存。
