VS Code扩展冲突是资源竞争、生命周期干预和API覆盖叠加的必然结果；高发于语言服务器、代码格式化和UI增强三类插件，需通过禁用组、项目级配置、日志分析及手动协调触发时机来解决。
VS Code 扩展冲突不是“偶尔发生”，而是资源竞争、生命周期干预和 API 覆盖叠加的必然结果——尤其当你装了多个格式化、语言服务或编辑器增强类插件时。
哪些扩展最容易互相打架
冲突高发区集中在三类插件：语言服务器（如 Pylance 和 Python 官方插件共存）、代码格式化（prettier 和 eslint 同时启用保存时格式化）、UI 增强（Bracket Pair Colorizer 2 和 Auto Rename Tag 都监听 onDidChangeTextDocument）。它们不是“不兼容”，而是对同一事件或同一文件路径做了重复/矛盾响应。
-
Prettier和ESLint都设为 “onSave” → 保存时可能只触发一个，或顺序错乱导致代码被覆盖两次 -
TabNine和GitHub Copilot同时激活 → 编辑器底层补全提供者注册冲突，Ctrl+Space补全菜单空白或卡顿 - 多个主题插件（如
Nord和One Dark Pro）启用 →workbench.colorTheme配置被覆盖，重启后回退到默认主题
用禁用组 + 启动配置隔离冲突场景
VS Code 不支持“插件沙箱”，但可用 "extensions.ignoreRecommendations" 和工作区级 settings.json 实现软隔离。关键不是删插件，而是按项目类型动态启用子集。
使用四维度框架评估任意 GitLab MR 或 GitHub PR 的复杂度：规模（20%），认知负荷（30%），审查工作量（30%），风险/影响（20%）...
- 在项目根目录建
.vscode/settings.json，写入："editor.formatOnSave": true,<br>"[javascript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" },<br>"[typescript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" },<br>"eslint.enable": false—— 明确关掉 ESLint 的自动修复，让 Prettier 全权负责 - 用
Ctrl+Shift+P→Extensions: Show Enabled Extensions，右键禁用非当前项目必需的插件（比如前端项目里禁用Go或Rust Analyzer） - 安装
Extension Manager插件（ID:wix.vscode-extension-manager），它能按文件夹保存启用状态快照，切换项目时自动还原
看日志定位谁在抢控制权
当出现光标跳转异常、保存无反应、补全失效等现象，别猜——直接查 Developer: Toggle Developer Tools 控制台，以及 Output 面板里选 Log (Extension Host)。
- 常见错误线索：
Cannot register language provider for 'python'. Another provider is already registered.→ 查出是ms-python.python和ms-python.pylance版本不匹配（Pylance 依赖特定 Python 插件版本） - 如果看到大量
Extension 'xxx' took xms to activate，说明某插件初始化阻塞了其他插件加载，优先禁用该插件 - 运行
code --status（终端命令）可输出当前所有扩展的激活耗时与内存占用，快速识别拖慢启动的元凶
真正难处理的从来不是“哪个插件该卸载”，而是两个插件都提供了你离不开的功能，但它们对 onWillSaveTextDocument 或 provideCodeActions 的实现逻辑互斥——这时候必须读插件源码里的 package.json 的 activationEvents 字段，手动协调触发时机，或者用 settings.json 中的 "editor.codeActionsOnSave" 精确指定只执行哪一类操作。
