VS Code插件管理关键在于按需启用、隔离环境、快速回滚；禁用插件可避免冲突与卡顿，支持全局或工作区级禁用，配置保留且不自动恢复；通过Startup Performance分析启动耗时，结合extensions.json实现项目级插件推荐与自动禁用。
VS Code 的扩展插件管理不靠“安装完就完事”，真正关键的是**按需启用、隔离环境、快速回滚**——否则很容易出现插件冲突、启动变慢、甚至编辑器卡死。
如何禁用某个插件而不卸载它
禁用比卸载更安全，尤其当你怀疑某个插件导致 Ctrl+S 卡顿或语法高亮异常时。直接在扩展视图里点击插件右下角的齿轮图标，选「Disable」即可。注意：禁用后该插件的命令（如 extension.sortLines）和快捷键全部失效，但配置项仍保留在 settings.json 中，下次启用时自动恢复。
- 禁用对工作区生效：可在当前文件夹下右键插件 → 「Disable (Workspace)」，这样换项目时不影响其他工程
- 禁用后重启 VS Code 不会自动启用，必须手动点「Enable」
- 某些插件（如
GitLens）禁用后，状态栏 Git 信息可能残留，需手动刷新窗口（Developer: Reload Window）
如何查看哪些插件拖慢了启动速度
VS Code 自带性能分析工具，不用猜。打开命令面板（Ctrl+Shift+P），运行 Developer: Startup Performance，会弹出一个表格，列出每个插件的「激活时间」和「main thread blocked ms」。重点关注「activation time」超过 300ms 或「blocked」值高于 100ms 的插件。
- 常见“慢启动”插件：
EditorConfig（读取多层.editorconfig）、Prettier（首次格式化触发依赖解析）、IntelliCode（加载模型文件） - 如果某插件只在特定语言中需要（比如
Python），建议设置"python.defaultInterpreterPath"后再启用，避免全局激活 - 启动耗时高 ≠ 功能差，有些插件（如
ESLint）只是首次检查时重，后续影响小
如何为不同项目配不同的插件集
VS Code 支持工作区级插件推荐和启用策略，不是靠手动开关。在项目根目录创建 .vscode/extensions.json，写入：
{
"recommendations": ["ms-python.python", "ms-toolsai.jupyter"],
"unwantedRecommendations": ["esbenp.prettier-vscode"]
}
保存后，其他协作者打开该文件夹时，VS Code 会提示「推荐安装这些插件」；而你自己如果已装了 prettier-vscode，它会被自动禁用（前提是没在用户级启用）。
-
extensions.json不控制是否安装，只影响推荐与默认启用状态 - 真正生效依赖于「插件未被用户级启用」，所以建议平时尽量用工作区禁用，少点「Always Enable」
- 团队项目中，把这个文件提交到 Git，能显著减少新成员配置成本
插件管理最难的不是装多少，而是搞清「谁在什么时候被激活」「它的资源开销落在哪条线程上」。很多问题其实不是插件本身有问题，而是它被放在了错误的作用域里——比如把本该只在前端项目用的 Auto Rename Tag 全局启用，结果在写 Python 时也监听所有文件变化。
