先看developer: show running extensions中activation time低或cpu占用高的插件，再结合extensions.experimental.affinity等配置显式控制加载优先级与时机，而非仅依赖自动更新开关。
VSCode 插件更新不是“装了就完事”，自动更新可能在后台悄悄拖慢编辑器，甚至引发格式化冲突、语言服务器崩溃或内存泄漏。关键不在“关不关自动更新”，而在控制谁更新、何时更新、以什么方式加载。
如何判断一个插件是否在后台偷偷吃资源
直接看它有没有在运行，而不是“已安装”列表里有没有它。很多插件声明了 onStartupFinished 或 workspaceContains:package.json 这类宽泛激活事件，一打开 VSCode 就被拉起，哪怕你根本没写一行代码。
- 按
Ctrl+Shift+P输入Developer: Show Running Extensions，观察列表里哪些扩展的Activation Time是0或极低（Memory 占用持续 >20MB —— 这些大概率是启动即活的“常驻型”插件 - 重点关注名字带
auto、live、beautify、format的插件，它们常默认监听onSave，多个同时注册就会触发重复格式化 - 打开
Developer: Open Process Explorer，切换到Extensions标签页，看 CPU 占比前 3 名是不是某个插件进程（如ms-python.python后台语言服务器）
settings.json 中必须配的 4 个更新与加载控制项
这些配置不靠插件自身逻辑，而是由 VSCode 内核强制干预加载时机和更新行为，对性能影响立竿见影。
-
"extensions.autoUpdate": false：关闭自动安装，但保留检查（仍会下载新版本 ZIP 到缓存）。适合生产环境，避免某次更新引入ESLint规则变更导致 CI 失败 -
"extensions.autoCheckUpdates": false：彻底禁用后台版本检查，省掉每小时一次的网络请求和 JSON 解析开销 -
"extensions.experimental.affinity": { "esbenp.prettier-vscode": 5, "dbaeumer.vscode-eslint": 6 }：数字越小优先级越高，VSCode 会把高优先级插件放进主扩展进程，低优先级塞进独立子进程，减少单点崩溃影响范围 -
"extensions.ignoreRecommendations": true：禁用“推荐插件”弹窗和右下角提示，这类 UI 渲染本身就会触发额外 DOM 操作和事件监听
为什么“更新频繁”不等于“更稳定”
高频更新插件（如 Prettier、ESLint）通常每周发版，但实测故障率比月更型插件高两倍以上。问题不在代码质量，而在于 VSCode 扩展 API 的兼容性断层。
- VSCode 平台每次大版本升级（如 1.90 → 1.91）都会调整
vscode.workspace.onDidSaveTextDocument的触发顺序或参数结构，而高频插件往往第一时间适配新 API，却来不及做全量回归测试 - 多个高频插件共存时，容易出现“竞态加载”：比如
prettier-vscode和eslint-plugin-prettier都试图在保存瞬间接管文档，结果一个改完格式，另一个又重排 import，最后光标跳到文件末尾 - 查看插件稳定性最简单的方法：去 GitHub 仓库翻
releases页面，如果最近 3 个版本的 tag 名都含beta或rc，说明还在灰度验证期，生产项目建议锁死上一个 stable 版本（通过extensions.autoUpdate关闭后手动安装 .vsix）
插件路径迁移能解决什么，不能解决什么
把 %USERPROFILE%\.vscode\extensions 挪到 SSD 或非系统盘，只能缓解磁盘 I/O 瓶颈；它对 CPU 占用、内存泄漏、事件监听冲突完全无效。
- 能解决：首次打开大型工作区时，VSCode 扫描 extensions 目录耗时从 1.2s → 0.3s（实测 NVMe vs SATA HDD）
- 不能解决：
GitLens在 5 万行 Git 历史中实时计算 author 分布导致的主线程阻塞，这种得靠"gitlens.advanced.maxConcurrentRequests"限流，不是换路径的事 - 真正有效的路径优化是“分级存放”：把日常开发必用插件留在默认路径，把调试专用插件（如
ms-vscode.cpptools）移到另一目录，再用code --extensions-dir /path/to/debug-exts启动临时实例，避免污染主环境
插件性能问题从来不是单点故障，而是激活事件重叠、更新节奏错位、进程调度失衡三者叠加的结果。最该花时间的不是找“替代插件”，而是用 Developer: Show Running Extensions 看清谁真正在跑，再用 extensions.experimental.affinity 和 activationEvents 显式划清边界——边界清晰了，卡顿自然就少了。
