用安全模式启动并观察控制台reloading plugin日志顺序，结合禁用插件对比加载延迟，可定位拖慢启动的插件；重点排查LSP类、SublimeLinter、GitGutter等启动时同步阻塞的插件。
怎么确认哪个插件拖慢了 Sublime 启动
Sublime Text 启动慢，90% 是插件加载耗时导致的；plugin_host 进程本身不暴露具体插件名，但启动日志会按顺序打印每个插件的加载动作——关键就是让这些日志可见。
最直接的办法：关闭所有插件后逐个启用，同时观察控制台输出时间戳。不需要第三方工具，靠 Sublime 自带机制就能定位。
- 用
subl --safe-mode启动（Windows/macOS/Linux 均支持），此时plugin_host不加载任何插件，启动应快于 1 秒 - 正常启动一次，打开控制台（
Ctrl+`），记下最后一行类似reloading plugin XXX.YYY的时间点 - 重启并禁用一半插件（通过
Package Control: Disable Package），再对比控制台中reloading plugin行的出现间隔和延迟 - 重点盯住那些在
reloading plugin后紧跟ImportError、SyntaxError或长时间无响应的插件——它们往往在__init__.py里做了阻塞操作（比如同步读大文件、调用未安装的 CLI 工具）
为什么 print() 和 time.time() 在插件里不生效
因为 Sublime 插件运行在嵌入式 Python 解释器中，print() 默认输出到控制台，但只有插件成功加载后才可见；如果插件在导入阶段就崩溃（比如语法错误、路径错），print() 根本没机会执行。
真正有效的调试起点是控制台第一行日志：startup, version: 4xxx 后紧跟着的每条 reloading plugin 都代表一个插件开始加载。加载卡住的位置，就是问题插件所在。
- 不要在
__init__.py顶部写time.sleep(2)测试——这会让整个 UI 卡死，且异常可能被吞掉，控制台只显示空白 - 想测单个插件耗时，可临时在它的主模块（通常是
plugin_name.py）开头加：import time; print(f"[{time.time():.3f}] start loading {__name__}") - 如果该行没出现在控制台，说明插件根本没走到这里——检查文件是否放在
Packages/插件名/下、后缀是否为.py、是否有同名文件冲突 -
logging模块默认不输出到控制台，必须显式配置 handler，不如直接用print()
哪些插件最容易成为启动瓶颈
LSP 类插件（如 LSP-json、LSP-typescript）、自动补全类（AutoFileName、SublimeCodeIntel）、实时校验类（SublimeLinter）是高频嫌疑对象。它们不是单纯“加载快慢”问题，而是启动时就尝试连接外部进程或扫描目录。
-
LSP插件会在加载时尝试启动语言服务器，若node不在PATH或服务器二进制缺失，会卡在starting...日志上反复重试 -
SublimeLinter默认对所有文件类型启用，哪怕你只写 Markdown，它也会尝试找markdownlint并超时等待 -
GitGutter在项目根目录有.git时，会立即执行git status，遇到大仓库或网络挂载盘时可能阻塞数秒 - 检查插件设置里是否有
"disabled": false却没配"enabled": true的矛盾项——有些插件靠这个开关控制是否初始化，留空等于默认启用
控制台日志怎么看才不漏关键信息
Sublime 控制台滚动快、清屏频繁，尤其重启后日志全丢。不能只看最后几行，得抓住三个关键信号：
- 第一行
startup, version: 4xxx—— 启动时间基准点 - 每条
reloading plugin XXX.YYY前后的毫秒级时间差（控制台左侧有时间戳，需开启show_panel_on_build或手动记时） - 突然中断的加载序列：比如前 10 个插件都在 50ms 内完成，第 11 个之后 3 秒没新日志，那第 11 个就是目标
- 注意
ignored_packages设置是否生效：如果某插件出现在ignored_packages列表里，控制台不会出现它的reloading plugin行——但若拼写错误（比如写成"LSP"实际文件夹叫"LSP-json"），它仍会被加载
复杂点在于：插件加载顺序不固定，依赖关系会让某个插件的延迟“传染”给后续所有插件。所以看到卡顿位置，要往前推 2–3 个插件一起查。
