插件冲突可通过控制台报错、快捷键覆盖、插件加载失败等迹象定位；用安全模式隔离问题，再逐个禁用插件验证；检查key bindings文件确认覆盖顺序；启用sublime.log_input(true)排查按键是否被系统拦截。
插件冲突不是玄学，它一定在控制台里留了痕迹，或在快捷键绑定中露出破绽。
看控制台有没有报错或警告
打开 Sublime Text，按 Ctrl+` 调出控制台，一启动就盯住那里。插件冲突最常表现为：
-
Key binding ["ctrl+/"] overrides ["ctrl+/"]—— 说明两个插件（或插件与默认设置）抢同一个快捷键 -
ImportError: cannot import name 'create_connection'—— 插件用了 Sublime 不支持的 Python 标准库函数（比如从urllib.request导入create_connection） -
error loading plugin XXX.XXX或堆栈顶部出现package_control.py—— 很可能是插件加载失败引发连锁崩溃
如果看到这类输出，直接记下插件名（如 SublimeCodeIntel 或 Vintage），下一步就聚焦它。
用安全模式快速隔离问题源
关掉 Sublime，然后：
- Windows/Linux：按住
Shift键再双击图标启动 - macOS：终端执行
subl --safe-mode
安全模式会禁用所有插件和用户配置。如果此时功能恢复正常（比如 Ctrl+C 能复制、代码补全回来了），那基本可以断定是插件导致的问题。接下来不需要猜，直接进 Preferences → Package Control → Disable Package，逐个禁用最近安装或更新过的插件，每禁一个就重启测试一次。
查快捷键谁在偷偷覆盖默认行为
按 Ctrl+Shift+P 输入 Preferences: Key Bindings，左右并排打开 Default 和 User 文件。重点做三件事：
- 在左侧（Default）搜你想用的快捷键，比如
ctrl+/，确认它原本该触发toggle_comment - 在右侧（User）和已安装插件目录（
Preferences → Browse Packages）里全局搜索同一组keys，看谁最后定义了它 - 注意插件自带的
Default.sublime-keymap文件——它们加载顺序在系统默认之后、User 之前，很容易“悄无声息”地覆盖原生行为
发现冲突行后，别急着删，先注释掉测试；若确认是某插件（如 Emmet）绑定了 ctrl+alt+enter 却没生效，大概率是它依赖的命令名写错了（比如 "command": "emmet_expand_abbreviation" 拼成 emmet_expand_abbr），Sublime 不报错但静默失败。
验证按键是否真的进了编辑器
很多“快捷键失效”根本不是 Sublime 的问题。在控制台输入：
sublime.log_input(True)
然后按你怀疑失效的组合键（如 Ctrl+C）。如果控制台完全没反应，说明按键在进 Sublime 前就被截了：
- 显卡控制面板（NVIDIA/Intel）里关掉
Ctrl+Alt+方向键类热键 - 输入法（搜狗、QQ拼音）默认用
Ctrl+Space切换中英文，一按就切走，Ctrl+C根本传不进来 - Windows Defender 或火绒把
sublime_text.exe当可疑进程终止——检查事件查看器里是否有 Event ID 1000，描述含Application Hang
真正难排查的，往往是那种“只在特定项目里失效”或“升级后突然不行”的情况：它可能不是单个插件作祟，而是多个插件对同一语言服务（比如 Python 的 LSP 支持）反复注册监听器，最终让通信管道卡死。这种时候，.codeintel 目录删了重索引、或干脆换用 LSP-pyright 替代 SublimeCodeIntel，反而比修配置更快。
