唯一可信的排查方法是启用sublime.log_input(true)和sublime.log_commands(true)：无输入日志说明被系统/输入法/驱动截断；有输入无命令日志说明绑定被覆盖或command名拼错；两者均有则需比对实际执行命令与预期是否一致。
没有真正可靠的“排查工具”，唯一可信的是 Sublime 自带的 sublime.log_input(True) 和 sublime.log_commands(True)。 所有第三方 Keymaps 插件列出的绑定都可能漏掉 context 限制、动态注册命令或系统级劫持，不能当作事实依据。
怎么确认按键是否进到 Sublime 里
这是排查起点，跳过它直接改配置等于蒙眼调参。按 Ctrl+`（反引号）打开控制台，输入：
sublime.log_input(True)
再按你怀疑失效的组合键（比如 Ctrl+/ 或 Esc）。观察控制台输出：
- 完全没输出 → 按键被系统/输入法/显卡驱动截断：Windows 用户查 NVIDIA 控制面板或 Intel Graphics Command Center 的热键；macOS 用户关掉「系统设置 → 键盘 → 快捷键」中 Spotlight 和输入源的同名组合；中文输入法默认占
Ctrl+Shift，切英文再试 - 输出类似
key evt: ctrl+shift+p→ 按键已送达，问题在绑定层或命令执行环节
怎么知道实际执行了哪个命令
在确认按键进来了之后，继续在控制台输入：
sublime.log_commands(True)
再按同一组合键，看控制台是否出现 command: 开头的日志。常见现象：
- 有
key evt但无command:→ 绑定被覆盖，或command字符串拼错（比如toggle_comment写成toggle_comments） - 有
command: emmet_expand_abbreviation但你想要的是toggle_comment→ 插件（如 Emmet）抢了绑定 - 两者都有，但命令名和你预期不一致 → 真正生效的是后加载的规则，不是你写的那条
为什么改了 User.sublime-keymap 还是不生效
Sublime 加载快捷键的顺序固定为：Default.sublime-keymap → 插件目录下的 Default.sublime-keymap → Preferences → Key Bindings – User。后加载者静默覆盖前一个，且不报错。
- 按
Ctrl+Shift+P输入Preferences: Key Bindings，左右并排打开 Default 和 User 文件 - 在左侧 Default 中搜你的组合（如
"ctrl+d"），确认原始命令是duplicate_line - 在右侧 User 和所有插件目录（
Packages/Vintage/、Packages/Emmet/等）中全局搜索相同"keys"字段 - 高危插件优先排查：
Vintage、Emmet、Origami、GitGutter
User.sublime-keymap 是纯 JSON 数组，语法错一点整份就静默失效：必须用英文双引号、数组末尾不能多逗号、不支持 // 注释。
安全模式和临时禁用插件是最省事的验证手段
运行 subl --safe-mode（命令行）启动 Sublime，如果快捷键恢复，就坐实是插件冲突。
- 不用猜哪个插件有问题，用
Package Control: Disable Package逐个关掉可疑插件 - 关掉
Vintage后Esc仍不工作？可能是键盘固件或 macOS 未勾选「使用 F1、F2 等键作为标准功能键」 - 注意：
Esc关面板、搜索框等行为是内核硬编码，**绝不能**在User.sublime-keymap里重绑它——会破坏原生逻辑
真正容易被忽略的点是：日志开关必须手动关掉（sublime.log_input(False)），否则控制台持续刷日志；还有，JSON 错误只在右下角闪一下红字提示，一晃就过，得盯紧。
