最硬核验证方式是进安全模式：Windows/Linux按住Ctrl键再双击启动，macOS运行subl --safe-mode；若Package Control: List Packages返回空列表且操作丝滑，则问题100%出在插件或配置上。
怎么确认真是插件冲突而不是其他问题
启动后几秒内光标不动、方向键失灵、Ctrl+P 延迟超 2 秒，或任务管理器里 sublime_text.exe CPU 占用长期 >80%，基本可锁定为插件层问题。最硬核验证方式是进安全模式：Windows/Linux 按住 Ctrl 键再双击图标启动，macOS 运行 subl --safe-mode；启动后立刻按 Ctrl+Shift+P 输入 Package Control: List Packages，若返回空列表，才算真正隔离成功——此时若操作丝滑，问题 100% 出在插件或配置上。
控制台里盯哪几行日志能快速锁定问题插件
打开控制台（Ctrl + `），别扫全屏红字，只看堆栈最顶上 2–3 行：
-
File "./Packages/XXX/xxx.py"→ 记下XXX，90% 就是它 -
ImportError: cannot import name 'create_connection'→ 插件硬用了urllib.request.create_connection，但 Sublime 内置 Python 3.3 不支持这个函数 - 反复刷
Key binding ["ctrl+/"] overrides ["ctrl+/"]→ 至少两个插件绑了同一快捷键，UI 线程卡死不崩溃，但响应延迟明显 - 末尾有
plugin_host has exited unexpectedly且前面没报错 → 很可能插件在on_activated或on_load里写了死循环或内存越界
禁用插件必须走 Package Control，不能删文件夹
手动删 Packages/SomePlugin 文件夹无效：Sublime 仍会从 Installed Packages/SomePlugin.sublime-package 加载。正确流程是：
- 进
Preferences → Package Control → Disable Package，选中目标插件名（注意大小写，emmet和Emmet算两个插件） - 必须彻底退出 Sublime（Windows 查任务管理器确认
sublime_text.exe进程消失；macOS 用活动监视器查） - 再启动，测试是否还卡
- 如果禁用 A 后卡顿变轻但没消失，说明存在依赖链：A 插件调用了 B 插件的函数，B 崩溃导致 A 报
NoneType is not callable，得从底层插件开始禁
哪些插件禁用后最可能立竿见影
不是所有插件都平等拖慢性能。以下几类在启动或激活时就执行阻塞操作，禁用后卡顿常立刻缓解：
-
GitGutter（尤其 v1.x）：Windows 上频繁调用ReadDirectoryChangesW扫描仓库，大项目直接冻结 UI -
sublime-lsp/pylsp：默认全项目加载，一打开 Python 项目就开始后台解析，CPU 拉满 -
SideBarEnhancements：右键菜单初始化时遍历整个项目结构，含node_modules的目录会卡数秒 -
AutoFileName：启动即递归收集所有路径，遇到几十万文件的目录直接卡死 -
Package Control自身：默认开启自动升级，每次启动都尝试连 GitHub，国内网络下常 timeout 卡住主线程
真正麻烦的从来不是单个插件，而是缓存 + 索引 + 插件配置三者叠在一起的隐性耦合；每次重装插件前，先清 Cache 目录再关 "index_files": false，能省掉大半排查时间。
