唯一可信的排查方法是启用sublime.log_input(true)和sublime.log_commands(true)，通过控制台日志判断按键是否被系统截断、绑定是否被覆盖或命令名拼错；user.sublime-keymap语法错误会静默失效，加载顺序为default→插件default→user。
Sublime Text 的按键配置文件本身不“修改默认”，只靠加载顺序和语法正确性来覆盖——写错一个逗号，整份 User.sublime-keymap 就静默失效。
怎么确认按键进了 Sublime 而不是被系统吞了
这是所有排查的起点。按 Ctrl+` 打开控制台，输入 sublime.log_input(True) 回车，再按你怀疑失效的组合键（比如 Ctrl+Shift+P 或 Esc）：
- 控制台完全没输出 → 按键没进 Sublime，问题在外部：Windows 查 NVIDIA 控制面板 / Intel Graphics Command Center 的热键；macOS 查系统设置 → 键盘 → 快捷键里 Spotlight 和输入源是否占用了同名组合；中文输入法（搜狗、QQ 拼音）默认拦截
Ctrl+Shift，切英文再试 - 有输出（如
key evt: ctrl+shift+p）→ 按键已进入，问题在 Sublime 内部绑定逻辑
为什么改了 User.sublime-keymap 还是不生效
Sublime 加载快捷键的顺序是：Default → 插件自带的 Default.sublime-keymap → User.sublime-keymap。后加载者静默覆盖前一个，且不报错。
- 按
Ctrl+Shift+P输入Preferences: Key Bindings，左右并排打开两个文件 - 在左侧（
Default）中搜索目标组合（如"ctrl+d"），确认它原本应触发哪个command - 在右侧（
User）和所有插件目录（Packages/Vintage/、Packages/Emmet/等）中全局搜索同一"keys"字段 - 只要某个插件的
Default.sublime-keymap里写了相同组合，你的User配置就压根不会执行
User.sublime-keymap 的 JSON 必须严格合法
这个文件是纯 JSON 数组，不是 JS 对象，也不是 INI 配置。格式错一点，整份配置就被忽略——右下角可能只闪一下红字提示，极易错过。
- 所有键名和字符串值必须用英文双引号包裹：
"keys"不是keys，"toggle_comment"不是toggle_comments - 数组结尾不能多逗号：
["ctrl+alt+f"],是错的，["ctrl+alt+f"]才对 - 不支持
//或/* */注释；想临时禁用某条绑定，要么删整行，要么改成无效命令："command": "not_a_real_command" - 保存（
Ctrl+S）后立即生效，无需重启
Esc、Cmd+B 这类键根本不在 Key Bindings 管辖范围内
Esc 关闭搜索框、命令面板、替换栏，是 Sublime 内核硬编码行为，不走任何 .sublime-keymap 流程。你在 User.sublime-keymap 里加 {"keys": ["escape"], "command": "hide_panel"} 不仅无效，还会破坏原生逻辑。
- 若
Esc失效，先运行subl --safe-mode：如果恢复，说明是插件劫持（常见于Vintage、Origami） -
Vintage插件需进Preferences → Package Settings → Vintage → Settings，设"exit_insert_mode_on_escape": false -
Cmd+B在 macOS 上常被 Finder 或 Dock 占用，排查路径是：系统设置 → 键盘 → 快捷键 → 应用快捷键，搜索并删掉对应条目
真正容易被忽略的点是 context 条件——有些插件的快捷键只在特定文件类型或选中状态下才触发，这种冲突不会出现在全局搜索里，得靠 sublime.log_commands(True) 配合手动操作才能定位。
