先用 sublime.log_input(true) 确认按键是否进入 sublime：无输出说明被系统/输入法截断，有 key evt 日志则问题在内部绑定层；再按加载顺序检查 default→插件→user 文件中的冲突绑定，并确保 json 格式正确。
Sublime Text快捷键冲突不是配置没生效，而是你写的那条规则根本没机会执行——它被后加载的绑定静默覆盖了，或者压根没收到按键信号。
怎么确认按键是否真正进入 Sublime
这是所有排查的起点，跳过它直接改 User.sublime-keymap 等于在黑箱里调参。按 Ctrl+` 打开控制台，输入 sublime.log_input(True) 回车，再按你怀疑失效的组合键（比如 Ctrl+/、Cmd+Shift+P）。
- 控制台完全没输出 → 按键被系统/输入法/显卡驱动截断：Windows 查 NVIDIA 控制面板热键、Intel Graphics Command Center；macOS 去「系统设置 → 键盘 → 快捷键」关掉 Spotlight 和输入源切换项
- 有
key evt: ctrl+shift+p类日志 → 按键已送达，问题在 Sublime 内部绑定层
为什么改了 User.sublime-keymap 还是无效
因为 Sublime 的快捷键加载顺序是：Default → 插件目录下的 Default.sublime-keymap → User.sublime-keymap。后加载者无条件覆盖前一个，且不报错、不提示。
- 打开
Preferences → Key Bindings，左右并排看两个文件 - 在左侧（Default）搜你想用的组合，比如
"ctrl+d"，确认它原本对应duplicate_line - 在右侧（User）和所有插件目录（
Preferences → Browse Packages）中全局搜索同一"keys"字段，找到最后定义它的那个文件 - 高危插件：Vintage、Emmet、Origami、SideBarEnhancements —— 它们的
Default.sublime-keymap文件常自带大量覆盖性绑定
User.sublime-keymap 写错 JSON 就等于没写
这个文件是纯 JSON 数组，不是 JS 对象，也不是 INI 配置。一个标点错误就会让整份配置静默失效，右下角红字提示一闪而过，极易忽略。
- 必须用英文双引号包裹所有键名和字符串值：
"keys"不是keys，"ctrl+alt+f"不是'ctrl+alt+f' - 数组结尾不能多逗号：
["ctrl+alt+f"],是错的，["ctrl+alt+f"]才对 - 不支持任何注释：
//或/* */会直接导致解析失败；想临时禁用某条，删整行，或改成"command": "not_a_real_command" - 保存（
Ctrl+S）后立即生效，但若某个插件的Default.sublime-keymap也在更晚阶段绑定了相同keys，你的规则仍不会触发
Esc、Tab、Cmd+B 这些键根本不在 Key Bindings 管辖范围内
关闭命令面板、搜索框、替换栏这些行为是 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）劫持 -
Cmd+B在 macOS 上常被 Finder 或 Dock 占用：去「系统设置 → 键盘 → 快捷键 → 应用快捷键」搜索并删掉重复项 -
Tab被 Emmet 接管？别改插件的 User Key Bindings 文件（它不被加载），必须把修复规则写进Preferences → Key Bindings右侧的 User 文件，并确保 context 条件匹配实际使用场景
最易被忽略的点是：按键没进编辑器，和按键进了但被覆盖，是两类完全不同的问题，排查路径完全不同。先用 sublime.log_input(True) 切分问题域，再决定该查系统设置，还是翻插件目录，或是重审 JSON 格式 —— 否则所有修改都在原地打转。
