code --status可暴露90%启动卡顿根源，重点查Extensions区activationTime＞200ms的扩展（如eslint、gitlens）、files.watcherExclude是否漏配node_modules等目录、autoAttachChildProcesses是否干扰调试。
直接看 code --status 输出，它会暴露 90% 的启动卡顿和配置异常根源。
用 code --status 查扩展激活耗时
VSCode 启动慢，往往不是编辑器本身慢，而是某个扩展在后台“赖着不走”。code --status 命令会列出所有已加载扩展的激活状态和耗时。重点关注 Extensions 区域里 activated 状态且耗时 >200ms 的扩展——尤其是那些 Activation Events 是 * 或 onStartup 的，比如 eslint、gitlens、prettier。
实操建议：
- 按
Ctrl+Shift+P输入Developer: Startup Performance，查看更细粒度的加载时间分解 - 右键扩展 →
Disable (Workspace)，先禁用再判断是否真需要 - 点开扩展详情页，看
Activation Events字段：优先保留onCommand:xxx这类触发式激活，避开通配符*
检查 files.watcherExclude 是否漏配
Node 项目里 node_modules 是文件监视器的天敌。没排除它，几万个小文件变更会持续触发 inotify 事件，导致 Code Helper (Renderer) 进程 CPU 飙高、打字卡顿、Git 状态刷新延迟。
实操建议：
- 必须在项目根目录的
.vscode/settings.json中配置，用户级设置无效 - 至少写这四条：
"**/node_modules/**": true、"**/dist/**": true、"**/build/**": true、"**/.git/**": true - Linux/macOS 用户顺手跑
cat /proc/sys/fs/inotify/max_user_watches，若低于524288，执行echo 524288 | sudo tee /proc/sys/fs/inotify/max_user_watches - 改完配置后，必须关掉整个 VSCode 窗口再重开，热重载不生效
排查调试器自动附加子进程干扰
Node.js 调试时，VSCode 默认开启 autoAttachChildProcesses。如果项目里频繁调用 child_process.fork() 或 spawn()，调试器就会反复握手、等待、超时、重试——这个过程同步阻塞 UI 线程，直接拖慢启动。
实操建议：
- 在项目级
.vscode/launch.json的configurations中加："autoAttachChildProcesses": false - 同时加上
"skipFiles": ["<node_internals>/**"]，避免单步进 Node 内部代码 - 真要调试子进程时，手动用
Debug: Attach to Node Process命令连接，比自动附加稳定得多
真正容易被忽略的是：这些配置项之间存在隐式依赖——比如 files.watcherExclude 没生效，code --status 就可能误报成“扩展慢”，而实际是文件监听压垮了主线程。排查时别只盯着一个信号，得把命令输出、配置位置、重启动作三者对齐才有效。
