唯一可靠的方法是打开控制台执行sublime.log_input(true)和sublime.log_commands(true)验证按键事件与命令触发是否连贯；若log_input无输出，说明按键被系统/驱动/输入法截断；若有key evt但无command输出，则绑定被覆盖、拼写错误或context不匹配；两者皆无则问题在sublime外部。
唯一可靠的方法是打开控制台，执行 sublime.log_input(True) 和 sublime.log_commands(True)，看按键事件和命令触发是否连贯；其他所有“查看绑定列表”的方式都会漏掉动态注册、context 限制或插件劫持的条目。
怎么确认按键是否真正进入 Sublime
这是排查的第一步，跳过它等于在黑盒里调参。按 Ctrl+` 打开控制台，输入：
sublime.log_input(True)
再按你怀疑失效的快捷键（比如 Ctrl+/ 或 Cmd+Shift+P）：
- 控制台**完全没输出** → 按键被系统/显卡驱动/输入法截断（Windows 查 NVIDIA 控制面板热键，macOS 关「输入源」快捷键，中文输入法切英文再试）
- 输出类似
key evt: ctrl+shift+p→ 按键已送达 Sublime，问题出在绑定层
怎么判断是哪个绑定在起作用
在确认按键进来了之后，继续在控制台输入：
sublime.log_commands(True)
再按同一组合键，观察输出：
- 有
key evt但无command:行 → 绑定被覆盖、command名拼错（如toggle_comment写成toggle_comments），或context不匹配（例如只在 Markdown 语法下生效） - 出现
command: show_overlay {"overlay":"command_palette"}→ 命令确实触发了，只是行为不符合预期（比如被 Emmet 或 Vintage 插件接管） - 两者都无输出 → 问题不在 Sublime 内部，回到上一步查系统拦截
为什么改了 User.sublime-keymap 还是没用
因为 Sublime 加载顺序是：Default.sublime-keymap → 插件目录下的 Default.sublime-keymap → Key Bindings – User。后加载者静默覆盖前加载者，且不报错：
- 用
Ctrl+Shift+P输入Preferences: Key Bindings，左右并排打开 Default 和 User 文件 - 在左侧 Default 搜你的组合键（如
"ctrl+/"），确认原command是toggle_comment - 在右侧 User 和
Packages/下所有插件文件夹中全局搜索"ctrl+/"，看谁最后定义了它（Vintage、Emmet、Origami 常在这里偷偷重绑） -
User.sublime-keymap是纯 JSON 数组：必须用英文双引号、数组末尾不能多逗号、不支持//注释——错一个字符就整份静默失效
Esc 键失效或 Tab 键异常怎么办
Esc 关面板、关搜索框是 Sublime 内核硬编码行为，不走任何 .sublime-keymap 流程：
- 你在
User.sublime-keymap里加{"keys": ["escape"], "command": "hide_panel"}不仅无效，还会破坏原生逻辑 - 如果
Esc失效，先运行subl --safe-mode：恢复则说明是插件劫持（Vintage 需设"exit_insert_mode_on_escape": false，Origami 关close_on_escape） -
Tab被 Emmet 展开？不是简单禁用就能回退，它的行为由context控制，修复必须写到Key Bindings – User（不是 Emmet 自己的设置文件里）
真正难的不是找到哪条配置冲突，而是意识到 Sublime 的快捷键系统没有“冲突提示”，只有日志能告诉你信号走到哪一层就断了。别依赖插件列出的“全部绑定”，那张表根本看不见 context 条件、动态注册或加载顺序带来的覆盖。
