Sublime Text插件自动更新失效的根源在于Package Control的auto_upgrade与enable_upgrade_check双开关未对齐，且插件自身更新设置优先级更高；需确保二者均启用并配置在正确文件中，同时警惕非原子更新风险。
插件自动更新不是“开了就完事”，它会直接改写你的工作流——比如某天 Emmet 突然不补全、SideBarEnhancements 快捷键失效、甚至启动就崩溃。根本原因不是更新本身，而是 Package Control 的 auto_upgrade 和 enable_upgrade_check 两层开关没对齐，加上插件自身更新策略覆盖全局设置，导致更新行为不可控。
确认 Package Control 的 auto_upgrade 是否真生效
很多人以为在 Settings – User 里写了 "auto_upgrade": true 就万事大吉，但实际无效很常见：
- 该配置必须写在
Package Control.sublime-settings文件里，而不是 Sublime 主设置或其它插件设置中 - 文件语法必须严格合法：双引号、无尾逗号、大括号闭合，多一个空格都可能导致整行被忽略
- 保存后无需重启，但下次 Package Control 自动检查（默认每 12 小时）才触发；手动运行
Package Control: Upgrade Package不走 auto_upgrade 流程
enable_upgrade_check 被忽略是静默失败的主因
只开 auto_upgrade 相当于“准备好自动安装”，但没人去“检查有没有新版本”——enable_upgrade_check 才是那个定时发起网络请求的开关：
- 默认值为
true，但若你在用户设置里删掉了这一项，它不会继承默认值，而是 fallback 到false - 国内网络环境下，该请求常卡在
https://packagecontrol.io/channel_v3.json，控制台可能只显示Attempting to use Urllib downloader...然后无声超时 - 验证是否启用：打开控制台，执行
sublime.load_settings('Package Control.sublime-settings').get('enable_upgrade_check')，返回True才算真正开启
插件自身更新开关优先级高于 Package Control
像 Emmet、SideBarEnhancements 这类插件，会在自己的 Settings – User 里定义 "check_for_updates" 或 "auto_update"，一旦设为 false，哪怕 Package Control 全局开着，它也纹丝不动：
- 路径：Preferences → Package Settings → [插件名] → Settings – User
- Emmet 示例配置必须显式写
"check_for_updates": true，否则即使 Package Control 下载了新版，Emmet 仍运行旧版逻辑 - 某些插件（如
Origami）更新后会重置用户设置，导致你之前关掉的自动检查又被打开，意外触发更新
用延迟更新 + 手动确认替代全自动
真正稳定的方案不是“阻止更新”，而是把更新时机攥在自己手里：
- 关掉
enable_upgrade_check，保留auto_upgrade（这样你手动升级时仍能自动安装） - 每周固定时间运行
Package Control: Upgrade Package，逐个确认更新——尤其留意带 breaking change 的插件（如 v4.0+ 的SublimeLinter） - 对关键插件（如主题、代码补全类），在用户设置里加
"ignored_packages": ["插件名"]，更新前临时移除再重启，避免边用边更新引发状态错乱
最易被忽略的一点：更新不是原子操作。Package Control 下载新包、解压、覆盖旧文件、重载模块，中间任意一步失败（比如磁盘满、权限不足、文件被占用），都可能导致插件半残——这时控制台往往只报 reloading plugin XXX 然后沉默，得靠手动进 Packages/ 目录看文件时间戳和大小来判断是否真更新成功。
