用二分法快速定位VSCode扩展冲突源：先禁用一半扩展并重启测试，依结果在对应组中继续二分；重点关注prettier、eslint等格式化插件及命令注册冲突、CPU异常占用和底层库版本不兼容问题。
插件禁用后问题消失，怎么快速定位冲突源
VSCode 扩展冲突往往表现为：保存文件不触发格式化、快捷键失效、编辑器卡顿、右键菜单异常、甚至 Ctrl+S 无响应。最直接的判断依据就是「禁用所有扩展后问题消失」——这时别逐个启用，用二分法排查更高效：
- 先禁用一半扩展（推荐按类别：比如先禁用所有 LSP 类、再禁用所有主题/图标类）
- 重启 VSCode，测试问题是否复现
- 若复现，说明冲突在刚禁用的那组里；若不复现，则在另一组中继续二分
- 注意每次只改一组，且必须重启 VSCode（热重载可能掩盖状态残留）
特别留意名称含 prettier、eslint、editorconfig、beautify 的插件——它们常因重复注册 onSave 事件导致格式化冲突。
多个格式化插件共存时，如何强制指定默认 formatter
VSCode 不允许同时激活多个 formatter，但会按优先级自动选择一个。冲突常发生在你明确配置了 "editor.defaultFormatter"，却仍被其他插件覆盖。关键要看三处配置是否一致：
-
settings.json中的"editor.defaultFormatter"（全局或工作区级） - 当前文件类型专属设置，如
"[javascript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" } - 插件自身是否声明了
contributes.formats并匹配当前语言 ID（可通过插件package.json查看，或在命令面板运行Developer: Show Running Extensions观察激活状态）
常见陷阱：dbaeumer.vscode-eslint 在启用 "eslint.format.enable": true 时，会主动注册为 JavaScript/TypeScript 的 formatter，即使你设了 Prettier 为默认，它仍可能抢在 Prettier 前执行。
插件报错 "Command 'xxx' not found" 或 "Cannot register command" 是什么情况
这类错误本质是命令名冲突或注册时机异常。VSCode 要求每个命令（contributes.commands）全局唯一，两个插件若都注册了 extension.sayHello，后加载的那个会静默失败。典型表现：
- 快捷键绑定无效（如
Ctrl+Shift+P搜不到命令） - 插件提供的右键菜单项缺失
- 开发者工具 Console 报
Cannot register command 'xxx'. This command has already been registered.
解决方法不是删插件，而是查日志：Help > Toggle Developer Tools > Console，过滤 register command；再配合 Developer: Show Running Extensions 看哪些插件已激活但未正确初始化。重点检查近期更新或新装的插件，尤其是名字带 enhanced、pro、plus 的增强型工具集。
插件导致 CPU 持续 100% 或窗口假死，怎么看是哪个在作怪
不是所有插件都会在「扩展」视图里显示高负载。真正有效的排查路径是：
- 打开命令面板 → 运行
Developer: Open Process Explorer（不是系统任务管理器） - 观察
Extension Host进程下的子线程，按 CPU 排序 - 点击可疑扩展名，右侧会显示其调用栈和正在执行的
require路径 - 若看到大量
node_modules路径指向某个插件（如username.another-prettier），基本可锁定
特别注意那些监听全量文件变更的插件（比如做实时 lint 或 watch build 的），它们常在大型工作区中因 fs.watch 泄漏或递归扫描失控引发卡顿。关闭 files.watcherExclude 中未合理配置的目录（如 "**/node_modules/**" 必须显式排除）能显著缓解。
插件兼容性没有银弹，真正麻烦的永远是隐式依赖——比如 A 插件要求 vscode-languageclient@8.x，B 插件锁死在 7.x，而 VSCode 内置的版本又刚好是 7.5。这种底层库不一致的问题，连进程探查器都难直接暴露，只能靠禁用 + 日志 + 版本比对三者交叉验证。
