按键未进sublime是快捷键失效主因：先用sublime.log_input(true)验证，无输出则被系统/输入法/显卡热键拦截；有输出则查加载顺序、插件冲突、json语法错误或硬编码键。
Sublime Text 里快捷键“按了没反应”或“触发了别的命令”，90% 不是配置写错了，而是按键根本没进编辑器，或者被后加载的规则静默覆盖了。
Ctrl+B 或 Ctrl+/ 没反应？先看按键进没进 Sublime
这是所有排查的起点。按 Ctrl+` 打开控制台，输入 sublime.log_input(True) 回车，再按你想查的组合键（比如 Ctrl+B）。如果控制台**完全没输出**，说明信号在进 Sublime 前就被截断了：
- Windows 用户重点检查 NVIDIA 控制面板或 Intel Graphics Command Center 里的热键设置（尤其是
Ctrl+Alt+方向键类） - 搜狗、QQ 拼音等中文输入法默认占用
Ctrl+Shift或Ctrl+Space切换，切到英文输入法再试 - macOS 用户去「系统设置 → 键盘 → 快捷键」，关掉「Spotlight」和「输入源」中同名组合（哪怕你不用
Cmd+Space，它也可能干扰底层事件）
按键进了但命令不对？查加载顺序和谁最后定义了它
如果控制台输出类似 key evt: ctrl+b，说明按键已送达，问题出在绑定层。Sublime 加载快捷键的顺序固定为：Default（内置）→ 插件的 Default.sublime-keymap → User.sublime-keymap。后加载者会静默覆盖前一个，且不报错。
- 按
Ctrl+Shift+P输入Preferences: Key Bindings，左右并排打开两个文件 - 在左侧（
Default）搜索目标组合，确认原始命令（如ctrl+/对应toggle_comment） - 在右侧（
User）和所有插件目录（Packages/Vintage/、Packages/Emmet/等）中全局搜索相同"keys"字段 - 高危插件优先排查：
Vintage、Emmet、Origami、GitGutter
User.sublime-keymap 写错一个字符就等于没写
这个文件是纯 JSON 数组，语法容错率极低。错一个标点，整份配置就会被 Sublime 静默忽略——右下角可能只闪一下红字提示，稍不注意就错过。
- 必须用英文双引号：
"keys"不是keys，"toggle_comment"不是toggle_comments - 数组末尾不能多逗号：
["ctrl+alt+f"],是错的，["ctrl+alt+f"]才对 - 不支持任何注释（
//或/* */），想临时禁用某条，要么删整行，要么改成"command": "not_a_real_command" - 保存（
Ctrl+S）后立即生效，但若某个插件的Default.sublime-keymap里也有同keys且加载更晚，你的自定义仍不会执行
Esc、Tab 这些键根本不在 keymap 流程里
关闭搜索框、命令面板、替换栏这些行为是 Sublime 内核硬编码逻辑，完全不走任何 .sublime-keymap 文件。你在 User.sublime-keymap 里加 {"keys": ["escape"], "command": "hide_panel"} 不仅无效，还可能破坏原生交互（比如按 Esc 后面板卡住不隐藏）。
-
Esc失效？先运行subl --safe-mode：若恢复，说明是插件劫持（常见于Vintage或Origami） -
Tab被 Emmet 接管？修复必须写在正确的文件里：Preferences → Key Bindings（即User.sublime-keymap），而不是 Emmet 自己的设置页 - 别信第三方 Keymaps 插件列出的“全部绑定”，它漏掉 context 条件、动态注册、系统级劫持——唯一可信的是
sublime.log_input(True)和sublime.log_commands(True)
