先执行code --disable-extensions验证是否插件导致，若秒开则100%是扩展问题；再运行Developer: Show Running Extensions，重点排查Activation Time超1000ms或状态为Activating/Activation failed的插件。
VSCode 启动卡在 “Activating Extensions” 或编辑器响应迟钝，大概率不是硬件问题，而是某个扩展在启动阶段执行了同步 I/O、网络请求或全量文件扫描——这类行为会直接阻塞主线程，导致整个 UI 冻结。
怎么看哪个插件在拖慢启动
别猜，直接看 VSCode 自己的诊断数据。按 Cmd+Shift+P（macOS）或 Ctrl+Shift+P（Windows/Linux），输入并选择 Developer: Startup Performance。它会打开一个带时间轴的面板，列出主进程、渲染器、扩展激活等各阶段耗时。
重点关注 “Extension Activation” 区域里耗时超过 300ms 的条目；再配合 Developer: Show Running Extensions 查看哪些扩展状态长期卡在 “Activating…”。常见高嫌疑对象包括：GitLens、ESLint、Prettier、Remote - SSH，尤其是它们的 activationEvents 里含 onStartup 或 * 的版本。
- 如果某个扩展在
Startup Performance里显示 “Activating (sync)” —— 基本可以确定它用了同步 fs 操作，必须禁用或换替代方案 -
Remote - SSH在未连接远端时仍会尝试重连，建议在非远程场景下全局禁用 - 语言类扩展（如
Python、Java Extension Pack）若项目不涉及对应语言，禁用后启动可快 1–3 秒
files.watcherExclude 配置为什么经常失效
写了 "files.watcherExclude": {"**/node_modules/**": true} 却还是卡？常见原因有三个：路径没写对、规则被覆盖、系统 inotify 句柄不够。
第一，VSCode 的 watcher 排除是**前缀匹配 + glob 展开**，不是正则；**/node_modules/** 能匹配 /project/node_modules/foo/index.js，但写成 node_modules（缺前后通配符）就无效。第二，用户级 settings.json 和工作区级 .vscode/settings.json 同时存在时，后者优先级更高——检查你是不是在错误位置改了配置。
- Linux/macOS 下运行
cat /proc/sys/fs/inotify/max_user_watches，若低于524288，watcher 会静默退化为轮询，CPU 直接飙满 - macOS 上某些插件（如
Live Server）会绕过files.watcherExclude自行启动 chokidar 实例，得单独关掉它 - 禁用
files.useExperimentalFileWatcher（设为false）有时反而更稳，尤其在老旧内核或虚拟机中
延迟加载 extensionKind 怎么配才真正生效
"remote.extensionKind" 不是开关，而是一个“调度策略声明”：它告诉 VSCode “这个扩展只应在 workspace 环境里加载”，从而跳过本地冷启动阶段。但它只对支持多实例模式的扩展有效（如 ms-python.python、ms-vscode.vscode-typescript-next），对 prettier.prettier-vscode 这类纯前端格式化插件无效。
正确写法是在用户级 settings.json（不是工作区）中添加：
"remote.extensionKind": {
"ms-python.python": ["workspace"],
"ms-vscode.cpptools": ["workspace"]
}注意：该配置仅在你使用 Remote-SSH / WSL / Containers 时起作用；若你从不连远程，这条配置毫无意义，还可能干扰本地语言服务发现逻辑。
- 扩展 ID 必须完全准确，大小写敏感，可在扩展详情页 URL 里找到（如
https://marketplace.visualstudio.com/items?itemName=ms-python.python中的ms-python.python） - 值必须是数组，不能写成字符串
"workspace"，否则 VSCode 会忽略整条配置 - 改完后需**完全退出 VSCode 进程**（macOS 上 Cmd+Q，Windows 上右键任务栏图标退出），再重新打开才生效
轻量启动模式不是临时方案，而是诊断基准线
code --disable-extensions --disable-gpu --no-sandbox 这个命令的价值，不是让你日常这么用，而是建立一个“干净基线”：如果它启动秒开，说明问题 100% 出在扩展或 GPU 渲染层；如果它依然慢，就得查文件系统、磁盘 I/O 或用户数据目录损坏。
日常误操作是把它加进 Dock 或桌面快捷方式当主力入口——这等于放弃所有语言服务、Git 集成和调试能力。它唯一合理用途是：每次怀疑性能回归时，用它快速验证是否由某次更新或配置变更引发。
- Mac 用户注意：
--disable-gpu在 M 系列芯片上常导致文字模糊、滚动撕裂，应优先试--enable-gpu-rasterization - Windows 上若用
--disable-gpu后反而更卡，大概率是显卡驱动冲突，此时应清理%APPDATA%\Code\GPUCache - 真正需要长期启用的，只有
--disable-extensions—— 它能帮你确认是否该重装某个扩展，而不是反复调参
最常被忽略的一点：VSCode 的“启动完成”不等于“功能就绪”。很多语言服务器（如 tsserver、pylsp）会在窗口渲染后继续后台加载数秒，期间跳转、补全、悬停都不可用。这时看 Developer: Toggle Developer Tools → Console 里的 warning 日志，比盯着进度条有用得多。
