vscode启动慢八成因插件activationevents配置不当，如"*"或"onstartup"导致冷启动抢跑；应通过developer: startup performance和--prof-startup定位高耗时扩展，并用remote.extensionkind或activationevents优化延迟加载。
VSCode 启动慢，八成是加载项（即扩展）在“抢跑”——不是你没关它们，而是它们的 activationEvents 早就悄悄把代码塞进了内存。
为什么禁用扩展还不见效？看 activationEvents 才是关键
禁用一个扩展，只隐藏 UI 和命令入口，但它的 package.json 仍会被读取，监听器可能已注册。真正决定“是否加载”的是 activationEvents 字段。
-
"*"或"onStartup"：一启动就拉起整个插件，毫无商量余地 -
"onLanguage:typescript"：只在打开.ts文件时加载，安全 -
"workspaceContains:pyproject.toml"：比onLanguage:python更精准，避免单个临时.py文件触发
验证方式：执行 Developer: Show Running Extensions，观察目标插件的 Activation Time。若为 0ms 或 ，说明它根本没懒加载。
remote.extensionKind 不是远程专用，本地也能用作延迟加载开关
这个配置常被误认为只用于 SSH/WSL 场景，其实它是 VSCode 1.86+ 引入的通用延迟加载机制：把指定扩展强制设为 ["workspace"]，就能让它跳过冷启动阶段，等你真正打开对应工作区才初始化。
- 适用于 Python、Rust、Go 等语言服务器类扩展，ID 形如
ms-python.python - 必须写进
settings.json（全局或工作区），不能靠 UI 设置 - 值设为
["workspace"]表示“仅在该工作区激活”，设为["ui"]则仍会在主进程加载（不推荐）
示例配置：
{
"remote.extensionKind": {
"ms-python.python": ["workspace"],
"rust-lang.rust-analyzer": ["workspace"]
}
}
别信“启用/禁用”开关，Developer: Startup Performance 才是真相
界面里勾选“禁用”只是表象，真正拖慢启动的是那些在 Extension Host 阶段耗时超 200ms 的扩展。光靠感觉判断不准，得看数据。
- 启动 VSCode 后立刻按
Cmd+Shift+P→ 输入并运行Developer: Startup Performance - 重点关注 “Activation Time” 列，排序后一眼看出谁最贪吃
- 若某扩展显示
activated by another extension，说明它被别的插件“连带唤醒”，要顺藤摸瓜查源头
常见高耗时组合：GitLens + ESLint + Prettier —— 它们默认都监听 onStartupFinished，三者叠加极易突破 500ms。
--prof-startup 日志里藏着最硬的证据
当 Startup Performance 面板只能看到“扩展 A 耗时 320ms”，却不知道这 320ms 具体花在哪一行 require 上时，就得靠底层日志。
- 终端执行：
code --prof-startup --disable-extensions（先排除干扰） - 再执行：
code --prof-startup（带扩展启动） - 退出后生成
cpu-*.json，用chrome://tracing打开对比
重点追踪：extensionHost/activate 下的子任务，尤其是 require 某个 node_modules 子路径的耗时。很多问题出在插件内部用了未打包的大型依赖（比如某个 Markdown 插件偷偷 require 了整个 remark 生态）。
真正卡顿的从来不是“开了多少插件”，而是哪些插件在你还没点开任何文件时，就已经把整套逻辑链加载进内存并开始监听——优化起点永远是 activationEvents 和 Developer: Startup Performance 的交叉验证，而不是盲目删插件。
