先用sublime.log_input(True)验证按键是否进入编辑器：若控制台无输出，说明被系统（如显卡面板、输入法）截断；若有输出，则需对比Default与User键绑定文件，排查插件覆盖或context条件不匹配问题。

Sublime 里快捷键“按了没反应”或“执行了别的命令”，大概率不是坏了，而是被覆盖、截断或压根没进编辑器。关键得先分清：问题是出在 Sublime 外面，还是里面。

用 sublime.log_input(True) 确认按键是否进入编辑器

这是最直接的验证手段——它能告诉你系统按键事件有没有真正传到 Sublime 进程里。

• 按 Ctrl+` 打开控制台
• 输入 sublime.log_input(True) 并回车
• 再按你想查的组合键（比如 Ctrl+C）

如果控制台**完全没输出**，说明问题在外部：显卡控制面板（NVIDIA/Intel）、Windows 键盘热键设置、输入法（搜狗/QQ拼音常劫持 Ctrl+Shift）都在中途把按键吞了。此时改 Sublime 配置毫无意义。

如果控制台输出了类似 command: copy 或 key evt: ctrl+k，说明按键已进编辑器，问题在绑定逻辑或插件覆盖。

对比 Default 和 User 快捷键文件找覆盖点

Sublime 的快捷键加载顺序是：默认绑定 → 插件绑定 → 用户绑定，后加载者胜。冲突往往就发生在“后面盖掉了前面”。

• 按 Ctrl+Shift+P → 输入 Preferences: Key Bindings，左右两个文件同时打开
• 在左侧（Default）搜索你失效的组合，比如 "ctrl+/"，确认它原本该触发 toggle_comment
• 在右侧（User）和插件目录（Packages/插件名/Default.sublime-keymap）里全局搜索同一组合
• 只要某处更靠后的位置定义了相同 "keys"，它就生效；哪怕那条命令根本不存在，也会静默“吃掉”这个按键

别依赖“注释掉”来禁用——JSON 不支持 // 注释，删整行或改成 "command": "not_a_real_command" 才有效。

插件快捷键不一定是“冲突”，可能是“条件不满足”

有些插件（如 Vintage、Emmet）注册的快捷键带 "context" 条件，比如只在 Vim 模式下生效，或只在 HTML 文件中响应。你按了没反应，不是被覆盖，而是上下文不匹配。

• 在 Preferences → Package Settings → 插件名 → Key Bindings 查看该插件的完整绑定
• 留意是否有 "context" 字段，例如 [{"key": "selector", "operator": "equal", "operand": "source.css"}]
• 这类绑定不会出现在主 Key Bindings 窗口里，也不会和默认键直接冲突，但会“静默失效”

想绕过条件限制？可以在 User 文件里加一条无条件的同 key 绑定，但得确保 command 名写对，且不触发副作用。

JSON 格式错一个字符，整段配置就静默失效

Preferences → Key Bindings – User 是最终生效层，但也最脆弱。VSCode 会报红，Sublime 不会——它只是默默跳过整块非法 JSON。

• 必须用双引号包裹所有键名和字符串值，比如 "keys"，不能用单引号
• 数组末尾不能多逗号：["ctrl+f"], 是错的；["ctrl+f"] 才对
• 每条规则是对象，整个文件是 JSON 数组，开头是 [，结尾是 ]
• 改完务必 Ctrl+S 保存，Sublime 不自动保存文本文件

最容易被忽略的是：你改了 User，但某个插件的 Default.sublime-keymap 文件也在同一路径下、且加载顺序更靠后——这种“隐藏覆盖”得手动进 Packages/ 目录翻。