用subl --safe-mode（Windows/macOS/Linux）启动可跳过所有插件和用户设置，若卡顿消失则问题必在插件或配置；禁用插件须通过Preferences → Package Control → Disable Package并彻底退出进程后重启，不可仅删文件夹。
怎么用 safe-mode 快速确认是不是插件导致卡顿
启动时加 -safe-mode 参数是排查插件问题的第一步，它会跳过所有第三方插件和用户设置，只加载原生功能。Windows 下在命令行执行 subl --safe-mode，macOS 用 subl -safe-mode，Linux 类似。如果此时卡顿消失，基本能锁定问题出在插件或自定义配置上。
注意：-safe-mode 不等于“禁用插件”——它连 index_files、word_wrap 等用户设置也一并忽略，所以不能用来测试某项配置是否生效，只用于隔离插件干扰。
- 别靠手动删
Packages/PluginName文件夹，Sublime 仍会从Installed Packages/PluginName.sublime-package加载 - 正确禁用方式是 Preferences → Package Control → Disable Package，选中后必须彻底退出进程（检查任务管理器或活动监视器）再重启
- 如果禁用 A 插件后卡顿减轻但未消失，可能是 A 依赖的 B 插件仍在后台运行，得顺着控制台日志往底层查
怎么看控制台日志定位具体哪个插件在拖慢保存
保存文件卡三秒，大概率是某个插件注册了 on_post_save 并执行了耗时操作。打开控制台（Ctrl + `），清空后立刻保存一个普通文件，盯住顶部几行新输出：
- 看到
File "./Packages/XXX/xxx.py", line XX, in on_post_save→ 记下XXX，就是罪魁祸首 - 看到
SublimeLinter: linter 'eslint' took 2841ms→ 对应插件名和耗时直接暴露 - 反复刷
GitGutter: updating status或LSP: sending textDocument/didSave→ 优先检查 GitGutter、sublime-lsp 配置
这类日志不会报错，但延迟明显。没堆栈也不代表没插件在干活——有些只是静默轮询，得结合 CPU 占用率交叉验证。
哪些插件配置改动最能立竿见影
不是所有插件都能一刀禁用，有些是刚需（比如 GitGutter 显示修改状态）。与其全关，不如调低它的侵略性：
- GitGutter 设置里加
"non_blocking": true和"live_mode": false，让它不抢主线程、只在保存后异步更新 - LSP 插件全局设
"enabled": false，再在项目根目录的.sublime-project里按需开启，避免对非代码文件扫描 - 把
"index_files": false加进用户设置，否则即使插件被禁，GitGutter、SublimeLinter 仍可能偷偷 fork 子进程扫全文 - Java 类插件若调用外部 JVM，务必在构建系统里加
-Xms512m -Xmx1024m，防止 GC 频繁触发卡顿
为什么改完设置要彻底重启才生效
很多性能参数（比如 hardware_acceleration、plugin_timeout、large_file_size_limit）是在 Sublime 进程启动时就初始化的。仅重载设置或关闭再打开文件无效，因为 GPU 上下文、插件宿主（plugin_host.exe）、索引线程都还活着。
必须确认 sublime_text.exe（Windows）或 Sublime Text 进程已完全退出，再重新启动。macOS 上尤其要注意：关掉窗口 ≠ 退出进程，得用活动监视器强杀。
真正容易被忽略的是插件之间的隐式依赖——比如你禁用了 A，但 B 插件内部仍 try-import A 的模块，结果报 NoneType is not callable，表面看是 B 卡，实际得先修 A。
