先执行code --disable-extensions启动调试，若能正常命中断点、显示变量面板，则100%是调试插件依赖冲突；否则需排查launch.json配置或工具链（如GDB版本）。
怎么确认是调试插件的依赖冲突，而不是别的问题
VSCode 启动调试时卡在 “Starting debugger…”、断点不命中、控制台没输出，甚至直接报 Extension host terminated unexpectedly，这些现象背后大概率不是代码写错了，而是调试插件和它依赖的语言支持插件版本不匹配。最快速的验证方式：终端执行 code --disable-extensions，再打开项目启动调试。如果这时能正常进断点、看到变量面板 → 100% 是插件依赖冲突；如果还失败，就得查 launch.json 配置或工具链本身（比如 GDB 版本）。
Cortex-Debug + CH32V208 工具链：GDB 8.3 被拒的典型场景
沁恒 CH32V208 的 RISC-V 工具链（如 v1.70 SDK）自带 riscv-none-embed-gdb 8.3，而 Cortex-Debug v1.10.0+ 强制要求 GDB ≥9。这不是“你装得不对”，而是插件策略和芯片厂商工具链节奏错位。关键线索是调试控制台里明确出现：ERROR: GDB major version should be >= 9, yours is 8。
- 别急着升级 GDB —— 沁恒官方不提供 GDB 9+ 的嵌入式版本，强行编译容易破坏 SDK 兼容性
- 降级 Cortex-Debug 到 v1.4.4（2021 年发布），它是最后一个稳定支持 GDB 8.x 的版本
- 安装后务必在 settings.json 中加一句：
"cortex-debug.autoUpdate": false，防止 VSCode 自动升级回不兼容版 - 验证方式：检查
~/.vscode/extensions/marus25.cortex-debug-1.4.4/package.json里"version"字段是否为"1.4.4"
Unity 调试失效：C# 插件发布者变更引发的依赖断裂
“Debugger for Unity” 插件突然不激活，控制台提示找不到 ms-vscode.csharp，这不是插件坏了，而是微软把 C# 扩展的发布者从 ms-vscode 改成了 ms-dotnettools，但旧版 Unity 调试器还在按老名字找依赖。
- 手动安装新版 C# 插件（
ms-dotnettools.csharp）不能解决，因为 Unity 插件根本不认这个 ID - 必须降级回旧版 C# 插件：
ms-vscode.csharpv1.24.4 或更早（v1.25.0 是首个完全切换发布者的版本） - 安装路径需匹配：VSCode 会把
ms-vscode.csharp和ms-dotnettools.csharp当作两个独立扩展，共存时可能互相干扰 - 禁用自动更新：同样在 settings.json 中设
"extensions.autoUpdate": false，避免下次重启被覆盖
Volar / Vetur 共存导致 Vue 文件爆红
Vue 3 项目里同时启用 Vue.volar 和 octref.vetur，结果整个 .vue 文件语法高亮全白、Ctrl+Click 跳转失效、template 区域报一堆“Unknown directive”错误 —— 这不是配置漏了，是两个插件在抢 vue 文件类型的解析权。
- Volar 专为 Vue 3 设计，依赖
vue@^3.3.0；Vetur 主要面向 Vue 2，对 Vue 3 支持有限且已停止维护 - 执行
npm ls vue看项目实际版本，再查插件 peerDependencies：npm view @volar/vue3 peerDependencies，确认是否交集为空 - 彻底禁用 Vetur：在扩展面板里右键 →
Disable (Workspace)，不要只点停用图标，否则后台进程可能残留 - 若项目含 Vue 2 子模块，不要试图“两个都留着”，改用工作区设置隔离：
"files.associations": {"*.vue": "html"}临时绕过语言服务
真正麻烦的从来不是“哪个插件该卸载”，而是那些看不见的依赖绑定：一个插件的 peerDependencies 声明、另一个插件硬编码的包名、VSCode 自身对扩展 ID 的缓存机制。修复时盯住三样东西：npm ls 输出里的 UNMET PEER DEPENDENCY、调试控制台的原始报错文本、以及 ~/.vscode/extensions/ 下真实安装的目录名和 package.json 内容。
