应同时关闭package control的auto_upgrade和enable_upgrade_check两项设置，并手动清理残留临时文件、禁用插件独立更新功能，才能彻底杜绝自动更新对开发流程的干扰。
直接关掉插件自动更新，比等它弹窗再点×强十倍——因为中断开发流的从来不是弹窗本身，而是后台静默升级卡住文件监听、阻塞命令执行、或在保存瞬间触发重载。
Package Control 的 auto_upgrade 和 enable_upgrade_check 必须同时设为 false
只关 auto_upgrade 不够：它只控制“下载完是否自动安装”，而 enable_upgrade_check 控制“要不要联网查有没有新版本”。两者都开着，Package Control 每 12 小时就会悄悄发起 HTTPS 请求，可能卡在 DNS 解析、证书验证或代理隧道里，导致命令面板响应延迟、快捷键失灵、甚至 Ctrl+S 保存卡顿 1–2 秒。
-
auto_upgrade: 设为false后，即使检测到更新，也不会自动解压覆盖 -
enable_upgrade_check: 设为false才真正停掉定时轮询，切断源头 - 这两项必须写进 Package Control 的用户设置（
Preferences → Package Control: Settings – User），不是 Sublime 主程序的 Settings
某些插件自带更新开关，会绕过 Package Control 全局设置
像 SideBarEnhancements、Emmet、GitGutter 这类插件，内部硬编码了独立更新逻辑。即使你把 Package Control 的两项全关了，它们仍可能在启动时自己发请求、弹横幅、或后台拉取元数据——这正是开发流被无声打断的常见原因。
- 打开
Preferences → Package Settings → [插件名] → Settings – User - 搜索关键词：
check_for_updates、auto_update、update_check - 例如 Emmet 要确认
"check_for_updates": false；GitGutter 常见字段是"check_for_updates_on_startup": false - 这类配置优先级高于 Package Control，不关掉就等于留了个后门
升级失败残留的临时文件会持续干扰后续操作
当一次自动更新因网络中断或权限不足失败后，Package Control 会在 Packages/ 目录下留下未完成的 .tmp 文件夹或半解压的 .sublime-package，下次启动时它仍会尝试续传或校验，导致控制台刷屏报错、Ctrl+P 搜索变慢、甚至语法高亮延迟加载。
- 关闭 Sublime Text
- 进入
Packages/目录（Preferences → Browse Packages可快速打开） - 删除所有以
.tmp结尾的文件夹，以及名称含upgrade_或pending_的文件 - 检查
Installed Packages/目录下是否有同名的.sublime-package和对应文件夹共存（比如Emmet.sublime-package和Emmet/文件夹），删掉 .sublime-package 文件，只保留解压版
状态栏和命令面板里的“假活跃”提示容易误判问题根源
很多人看到右下角显示 Update available 或命令面板里出现 Upgrade Package，就以为更新还在跑。其实这只是 UI 缓存——update_check 和 enable_upgrade_check 都关了之后，这些文字只是没刷新而已，背后早已没任何网络活动。
- 在 Sublime 主程序的
User Settings中加"show_update_in_status_bar": false，状态栏立刻清空 - 命令面板里残留的升级命令不会自动消失，但只要 Package Control 设置正确，选中它也不会触发任何动作
- 真正要盯的是控制台（
Ctrl+`）：如果看不到upgrading、downloading、certificate verify failed这类日志，说明更新链路确实已断
最易被忽略的一点：macOS 上若 Sublime Text 没拿到「完全磁盘访问」权限，auto_upgrade: false 也救不了你——因为插件目录读写失败会导致 Package Control 内部状态错乱，进而反复重试、伪造“正在更新”的假象。先去系统设置里确认权限，再调配置。
