sublime.log_input(true)是验证按键是否进入sublime的唯一手段：控制台无输出说明被系统或外围软件截断，有输出则问题在sublime内部绑定层。
用 sublime.log_input(True) 确认按键是否进到 Sublime
快捷键“按了没反应”，90% 的情况是它压根没进编辑器。不是配置错了，而是被系统或外围软件截断了。sublime.log_input(True) 是唯一能验证这点的手段。
按 Ctrl+` 打开控制台，输入：
sublime.log_input(True)
再按你怀疑失效的组合键（比如 Ctrl+/、Ctrl+B、Cmd+Shift+P）：
- 控制台**完全没输出** → 按键被系统、显卡驱动（NVIDIA/Intel）、输入法（搜狗/QQ拼音默认劫持
Ctrl+Shift）、macOS 输入源快捷键等截走 - 输出类似
key evt: ctrl+shift+p→ 按键已送达，问题在 Sublime 内部绑定层
Windows 用户重点查 NVIDIA 控制面板「热键」和 Intel Graphics Command Center；macOS 用户去「系统设置 → 键盘 → 快捷键 → 输入源」关掉「选择上一个输入法」。
查加载顺序：Default → 插件 Default → User，谁在最后写谁赢
Sublime 不报错、不提示覆盖，只按固定顺序加载并静默覆盖。你写的 User.sublime-keymap 文件，加载顺序排在最后，但插件自带的 Default.sublime-keymap 文件加载在它之前——也就是说，插件可以合法地把你写的覆盖掉。
排查步骤：
- 按
Ctrl+Shift+P输入Preferences: Key Bindings，左右并排打开 Default（只读）和 User（可编辑） - 在左侧 Default 中搜索你想用的组合，比如
"ctrl+/"，确认原命令是toggle_comment - 在右侧 User 和所有插件目录（
Preferences → Browse Packages）中全局搜索同一"keys"字段 - 常见高危插件：
Vintage、Emmet、Origami、SideBarEnhancements，它们的Default.sublime-keymap里常藏有同名绑定
临时验证是否插件导致：运行 subl --safe-mode（命令行），如果快捷键恢复，就坐实是插件冲突。
User.sublime-keymap 写错 JSON 就等于没写
这个文件是纯 JSON 数组，语法错一点，整份配置就静默失效。右下角红字错误提示一闪而过，极易忽略。
必须严格遵守的规则：
- 所有键名和字符串值必须用英文双引号：
"keys"，不是keys；"command": "toggle_comment"，不能用中文引号或单引号 - 数组末尾不能多逗号：
["ctrl+alt+f"],是错的，["ctrl+alt+f"]才对 - JSON 不支持
//或/* */注释；想禁用某条绑定，要么删整行，要么改成无效命令："command": "not_a_real_command" - 保存（
Ctrl+S）后立即生效，无需重启
改完仍不生效？别急着重写，先去插件目录搜一遍——很可能某个插件在更靠后的位置又绑了一次相同 keys。
Esc 键根本不在 Key Bindings 流程里
关闭命令面板、搜索框、替换栏这些行为，是 Sublime 内核硬编码逻辑，不走任何 .sublime-keymap 文件。你在 User.sublime-keymap 里加：
{"keys": ["escape"], "command": "hide_panel"}
不仅无效，还会破坏原生逻辑——比如按 Esc 后面板卡住不隐藏。
Esc 失效的真实原因通常是：
- 插件劫持（如
Vintage把 Esc 当作退出插入模式，Origami用它关闭标签页）→ 进对应插件 Settings 关闭exit_insert_mode_on_escape或close_on_escape -
subl --safe-mode下仍无效，且sublime.log_input(True)无输出 → macOS 没勾选「使用 F1、F2 等键作为标准功能键」，或键盘固件层拦截
真正难缠的不是怎么改，而是很多人花几小时调 User.sublime-keymap，却从没意识到 Esc 根本不走这条路。
