code --status 是最直接有效的启动卡顿诊断入口，它开箱即用、不依赖插件、不修改配置，立即输出启动快照，重点关注 Extensions 区域中 activated 且 Startup Time > 200ms 的扩展。
code --status 是最直接有效的启动卡顿诊断入口，它不依赖插件、不修改配置，开箱即用就能告诉你“谁在拖慢启动”。
用 code --status 快速定位高耗时扩展
这是 VSCode 自带的轻量级诊断命令，执行后立即输出当前工作区的启动快照，关键信息全在 Extensions 区域：
- 重点关注
activated状态且Startup Time> 200ms 的扩展，比如dbaeumer.vscode-eslint、eamodio.gitlens、esbenp.prettier-vscode—— 它们往往注册了*或onStartup激活事件，一开就扫描、建索引、加载语言服务 - 若某扩展显示
activated但耗时几乎为 0，说明只是注册了监听器，还没真正干活；而Running+ CPU 持续波动的，才是正在后台吃资源的活进程 - macOS 用户注意：
code --status必须在终端中运行，不能从 Dock 启动后再执行，否则看不到真实启动阶段数据
加 --prof-startup 捕获冷启动热点（V8 级别）
当 code --status 显示多个扩展都耗时偏高，或怀疑是 VSCode 内核/渲染器自身问题时，需要用 Chrome V8 的采样能力深挖：
- 终端执行：
code --prof-startup --prof-startup-file=vscode-startup.log，然后打开项目 - 启动完成后，VSCode 会生成一个
.log文件，用 Chrome 浏览器打开chrome://tracing→ Load → 选该文件，就能看到从模块加载、JS 编译到扩展初始化的完整调用栈 - 这个参数唯一能覆盖 V8 初始化早期阶段，
--disable-extensions或Developer: Startup Performance都无法替代它 - 注意：日志文件默认写入当前终端所在目录，不是 VSCode 工作区根目录
--disable-extensions 是验证插件是否为元凶的黄金标准
这不是临时禁用某个插件，而是彻底绕过所有用户扩展，只跑 VSCode 原生内核——这是判断“卡顿是否由插件引起”的最干净方式：
- 关掉所有 VSCode 窗口，在终端执行：
code --disable-extensions /path/to/your/project - 做同样操作（如连续输入、保存、打开搜索面板），如果卡顿消失，100% 锁定是插件问题；如果依旧卡，就要转向
files.watcherExclude、GPU 渲染或系统 inotify 限制排查 - 该命令不会卸载或修改任何扩展状态，退出后一切恢复原状，比在 UI 里逐个禁用快得多也更可靠
- Windows 用户注意：若用快捷方式启动 VSCode，需右键 → 属性 → 在“目标”末尾手动添加该参数，否则无效
其他实用参数组合与易踩坑点
单靠一个参数往往不够，实际排查常需组合使用，但顺序和副作用必须清楚：
-
code --disable-gpu：当界面动画卡顿、滚动掉帧、窗口重绘异常时优先试，尤其 macOS Sequoia + 外接高刷显示器场景；但禁用后文本渲染可能变模糊，不是长期方案 -
code --user-data-dir=/tmp/vscode-test：用于排除用户级配置或缓存损坏干扰，/tmp下新建干净数据目录，避免影响日常设置；Linux/macOS 可用，Windows 要换成%TEMP%\vscode-test - 别混用
--prof-startup和--disable-extensions：前者需要扩展参与才能反映真实瓶颈，后者会让日志失去参考价值 - 所有参数必须在终端中执行，通过 Dock、开始菜单或文件关联打开的 VSCode 不会继承这些参数
真正卡住的地方，往往藏在 code --status 输出里那几行不起眼的 Startup Time 数字背后，而不是你想象中的“机器太旧”或“项目太大”。盯住它，比调一百次 settings.json 更有效。
