“检查更新”比“安装更新”更伤启动速度，是因为extensions.autoCheckUpdates=true会同步阻塞extensionHost初始化，发起网络请求并等待超时（默认约3秒），而安装更新仅在有新版本时异步触发磁盘I/O；即使无更新，HTTP连接探测仍强制延缓整个插件加载队列。
VSCode 插件自动更新本身不拖慢启动，但更新检查（autoCheckUpdates）和更新后残留的 activationEvents 会显著延长冷启时间。
为什么“检查更新”比“安装更新”更伤启动速度
VSCode 默认开启 extensions.autoCheckUpdates 和 extensions.autoUpdate，每次启动都会触发网络请求 + 本地元数据比对。这不是后台静默行为——它阻塞 extensionHost 初始化队列，尤其在弱网或 DNS 不稳时，单次检查可卡住 400ms+。
-
extensions.autoCheckUpdates: true：启动时主动向 marketplace 发起 GET 请求，校验所有已安装插件版本 -
extensions.autoUpdate: true：若发现新版，会同步下载并解压到~/.vscode/extensions/下临时目录，触发 fs 操作和磁盘 I/O - 即使没新版本，HTTP 连接超时（默认约 3s）也会让 extensionHost 等待完毕才继续加载其他插件
更新后插件仍用 * 或 onStartupFinished 激活，等于白更新
很多插件（如 ms-python.python、redhat.vscode-yaml）在新版本中并未收敛 activationEvents。你手动更新后，它们 package.json 里还是 "activationEvents": ["*"]，结果下次启动照旧全量拉起。
- 用
Developer: Show Running Extensions查看 “Active” 状态，再点右上角齿轮进 “Extension Details”，展开 “When” 字段确认当前生效的 activationEvents - 别信插件页面写的“支持按需加载”——得看它实际声明了什么，不是宣传文案
- 更新不改 activationEvents 的插件，禁用或设
extensions.experimental.affinity才是真解法
settings.json 中这三行配置必须一起关
单独关 autoUpdate 不够，因为检查动作还在；只关 autoCheckUpdates 也不行，残留的更新包可能引发后续冲突。必须同步清理这三项：
{
"extensions.autoCheckUpdates": false,
"extensions.autoUpdate": false,
"extensions.ignoreRecommendations": true
}
-
ignoreRecommendations防止 VSCode 在启动时扫描 workspace 并动态推荐插件（比如检测到package.json就推 ESLint），这个过程也走 activationEvents 路径 - 改完记得重启 VSCode，否则设置不生效——热重载不触发改配置项
- Windows 用户额外注意：
code --status输出里的extensionHost时间下降不到 100ms？大概率是某插件在后台偷偷调用了vscode.extensions.getExtension()触发隐式激活
真正影响启动的从来不是“有没有新版本”，而是“要不要现在就管这事”。把更新动作彻底移出启动路径，才是最干净的解法。很多人调了半天 affinity 却忘了关 autoCheckUpdates，结果优化效果打五折。
