VSCode冷启动慢主因是onStartup扩展、臃肿settings.json及损坏WorkspaceStorage；应禁用非必要启动扩展、精简配置、清空Workspaces文件夹，并正确设置extensions.affinity为2以启用预热。
冷启动慢？先看哪些扩展真正在后台跑
VSCode 冷启动卡顿，八成是某些扩展在 onStartup 事件下强行拉起进程。别信“已启用”列表，得看实际运行状态。
按 Cmd+Shift+P（macOS）或 Ctrl+Shift+P（Windows/Linux），执行 Developer: Show Running Extensions。这个面板只显示此刻真正在干活的扩展，重点关注 Activation Events 列含 onStartup 或 * 的条目——比如 esbenp.prettier-vscode、ms-python.python、gitlens.gitlens。
- 启动耗时超过 100ms 的，优先右键 →
Disable (Global)（全局禁用），不是卸载，留着备用 - 若只在某项目用 Python，就选
Disable (Workspace)，避免影响其他项目 - 禁用后必须完全退出 VSCode（包括托盘进程），再重启才生效
删掉这三类 settings.json 内容，冷启快 2 秒以上
用户级 settings.json（通过 Preferences: Open Settings (JSON) 打开）里堆砌的配置，会拖慢主进程初始化。实测清理后冷启动从 3200ms 降至 692ms。
重点删这三类：
- 已弃用项：
"editor.fontLigatures": true（新版默认开启，留着反而触发兼容层解析） - 冲突项：多个格式化相关设置共存，如同时存在
editor.formatOnSave和prettier.requireConfig，VSCode 会反复校验规则优先级 - 大段注释或条件配置：JSON 注释虽被支持，但解析器仍需逐行扫描，尤其当注释块夹在嵌套对象中间时
保留最简核心：字体大小、缩进、保存自动格式化开关、workbench.startupEditor 设为 "none"。
清理 WorkspaceStorage 缓存比清 Cache 更有效
窗口尺寸、折叠状态、终端历史这些元数据，不是存在 Cache 目录，而是持久化到 WorkspaceStorage。损坏的 WorkspaceStorage 会导致冷启动时反复重建 UI 状态树，卡在 window:ready 阶段。
路径位置：
- macOS：
~/Library/Application Support/Code/Workspaces（注意不是Cache） - Windows：
%AppData%\Code\Workspaces - Linux：
~/.config/Code/Workspaces
操作建议：
- 关掉所有 VSCode 实例后，直接删除整个
Workspaces文件夹（不是里面的子文件夹） - 重启 VSCode，它会重建干净的 workspace 元数据，首次打开略慢，后续稳定
- 别动
Cache目录——它只影响热启动预加载，对冷启动影响极小
启用预热策略前，先确认 extensions.affinity 设置是否生效
VSCode 2026 的 startup.preloadWorkspace 配合 extensions.experimental.affinity 能把常用扩展提前加载进共享内存页，但前提是 affinity 值被正确识别。
常见失效原因：
- 扩展 ID 写错：
ms-python.python不是python或ms-python - 值设为
1（默认）或0（禁止）——只有设为2才表示“仅在关联文件打开时加载”，这才是预热的前提 - 配置写在工作区
.vscode/settings.json里，而没写在用户级settings.json中，导致冷启动阶段不读取
验证方式：启动后执行 code --status，搜索 extension host 行，看对应扩展是否出现在活跃进程中；再开一个 .py 文件，观察 CPU 是否有瞬时峰值——有则说明 affinity: 2 生效。
