最直接的办法是打开控制台执行sublime.log_input(True)并按键查看输出；若无日志则被系统或输入法拦截。
怎么确认某个快捷键到底被谁占用了
最直接的办法是打开控制台看日志——Sublime 本身不提供“一键查冲突”面板，但有精准的底层反馈机制。按 Ctrl+`（Windows/Linux）或 Cmd+`（macOS）调出控制台，输入：sublime.log_input(True)
然后按下你怀疑有问题的组合键（比如 Ctrl+Shift+P），控制台会立刻打出类似这样的行：
key evt: ctrl+shift+p<br>command: show_overlay {"overlay": "command_palette", "text": ""}这就说明该按键确实被识别，并触发了
show_overlay 命令；如果完全没输出，说明系统或输入法已截获，Sublime 根本没收到。
如何对比默认和用户快捷键是否重复
菜单栏点 Preferences > Key Bindings，会并排打开两个文件：左侧是只读的 Default.sublime-keymap，右侧是可编辑的 User.sublime-keymap。关键不是“看有没有相同按键”，而是看“同一组按键是否绑定了多个命令”。例如：
- 左侧有
{"keys": ["ctrl+alt+f"], "command": "reindent"} - 右侧又写了
{"keys": ["ctrl+alt+f"], "command": "format_code"}
这种情况下，用户配置会覆盖默认，但如果你装了插件（比如 SublimeCodeIntel），它可能也在自己的 Default.sublime-keymap 里绑了 ctrl+alt+f，而这个文件加载顺序在用户配置之后（取决于插件加载时机），就可能出现“有时生效、有时不生效”的诡异现象。
为什么删掉一行快捷键后还是没用
常见原因有三个：
- JSON 格式错误：少了个逗号、引号没闭合、末尾多逗号——Sublime 不报错，但整个
User.sublime-keymap会被静默忽略 - 命令名写错：比如把
toggle_side_bar写成toggle_sidebar，Sublime 找不到对应命令，就当没这行 - 上下文限制（context）生效：某条绑定加了
"context": [{"key": "setting.is_widget", "operator": "equal", "operand": false}]，意味着只在普通编辑器中有效，在命令面板或查找框里就失效
验证方式很简单：临时清空 User.sublime-keymap 全部内容，保存，再试快捷键。如果恢复了，说明问题一定出在用户配置里。
插件快捷键怎么快速定位和禁用
插件自带的快捷键通常藏在插件包目录下的 Default (Windows).sublime-keymap 文件里，路径类似：Packages/SublimeCodeIntel/Default (Windows).sublime-keymap
但别手动改它——每次插件更新就会被覆盖。正确做法是：
- 用
Preferences > Package Settings > [插件名] > Key Bindings打开其用户级快捷键文件（如果存在） - 或者，在
User.sublime-keymap中显式覆盖，比如把插件的ctrl+space改成ctrl+alt+space - 更彻底的排查：用
Sublime Text > Help > Debug > Enable Safe Mode（macOS）或菜单中对应选项，安全模式下所有插件禁用，如果此时快捷键正常，就说明冲突源100%来自插件
真正容易被忽略的是：macOS 系统级快捷键（如 Spotlight 的 Cmd+Space、输入法切换的 Ctrl+Space）会直接吞掉按键事件，Sublime 连日志都打不出来——这时控制台里压根不会有任何输出，得先去「系统偏好设置 > 键盘 > 快捷键」里检查。
