快捷键冲突本身不会直接导致代码高亮插件失效，而是通过劫持f5或ctrl+shift+b等触发语言服务器启动的操作，使语义高亮初始化被静默阻断，仅保留textmate基础语法；需用快捷键排查器定位真实拦截者，并在禁用冲突项后手动补全带when条件的原生命令绑定。
快捷键冲突本身不会直接导致代码高亮插件失效——但它是典型“症状混淆”的诱因：你看到高亮没了，第一反应是语言服务崩了，其实真正卡住的是语言服务器的启动链路，而这个链路常被快捷键劫持者（比如某个扩展用 F5 触发自己的调试器初始化逻辑）意外阻断或降级。
为什么按 F5 或 Ctrl+Shift+B 失效会连带高亮异常
语言服务器（如 Pylance、Volar、TypeScript Server）往往在用户首次触发调试/构建/格式化等操作时才真正激活语义层。如果 F5 被 GitLens 或 Remote-SSH 拦截，它不报错，也不执行原命令，只是静默吞掉；结果就是 VS Code 认为“用户没启动调试”，于是延迟加载或跳过语义高亮初始化——你看到的全是 TextMate 基础语法（关键字灰白、无类型提示、defineProps 不变色），但右下角语言模式明明显示正确。
- 不是高亮“坏了”，而是语义解析压根没跑起来
- 检查 Output → Log (Extension Host)，搜
failed to activate或language server crashed，常能看到某服务卡在 waiting for debug session -
Volar: Take Over Mode必须手动触发，且仅重载窗口无效，得关掉整个 VS Code 再重开
用 Developer: Toggle Keybinding Troubleshooter 定位真实拦截点
别靠猜，VS Code 自带的排查器能暴露快捷键背后的真实调用链。启用后按 F5，面板会列出所有匹配项，重点关注带 ▶ 的绿色条目（当前生效项）：
- 若看到
gitlens.showQuickFileHistory或python.debug占着F5，说明语言服务器根本没收到启动信号 - 灰色条目 ≠ 无关，可能是
when条件不满足（如当前没打开 .py 文件），但一旦条件满足，它就会顶替原生行为 - 右键快捷键列表 → “复制命令 ID” 是最准的方式，避免手写拼错（比如
editorTextFocu少个 s）
禁用冲突快捷键后必须补上新绑定，否则高亮恢复不了
只删掉劫持者的快捷键配置（如 {"key":"f5","command":"-gitlens.showQuickFileHistory"}）会让 F5 彻底失能——VS Code 不会自动 fallback 到原生调试命令。你得手动补一条：
[{"key":"f5","command":"workbench.action.terminal.toggleTerminal","when":"terminalFocus"},{"key":"f5","command":"extension.hosted.github-issues.debug","when":"!terminalFocus && !editorTextFocus"},{"key":"f5","command":"workbench.action.debug.start","when":"editorTextFocus"}]
- 必须加
when条件，否则F5在终端里也会试图启动调试，干扰 shell - 顺序很重要：
workbench.action.debug.start要放在最后，确保编辑器聚焦时才触发 - 改完
keybindings.json后，务必重启 VS Code，因为语言服务器状态不会热更新
真正容易被忽略的点是：高亮失效时，90% 的人会立刻去查主题、删缓存、重装插件，却忘了语言服务器的启动时机依赖于用户交互事件——而这些事件，正被某个安静躺在角落里的快捷键规则悄悄劫持着。
