Package Control安装失败典型报错为ImportError: No module named 'package_control'或控制台卡住，主因是粘贴代码含不可见字符、混用ST3/ST4脚本、代理拦截或缓存残留；修复需纯文本中转代码、用官网ST4专用脚本、验证网络连通性、清缓存并彻底重启。
Package Control 安装失败的典型报错和修复路径
控制台执行安装命令后出现 ImportError: No module named 'package_control' 或直接卡住无响应，基本可以断定是安装未生效。这不是网络慢的问题，而是执行环节出了偏差。
- 复制时混入了不可见 Unicode 字符（尤其是从网页直接 Ctrl+C 的代码），建议用纯文本编辑器中转一次再粘贴
- Sublime Text 4 用户必须用 ST4 对应的安装代码——官网
packagecontrol.io页面会自动识别版本并展示正确脚本，别套用 ST3 的旧命令 - 公司内网或开了代理时，
urllib.request.urlopen可能被拦截，可在控制台先试运行import urllib.request; urllib.request.urlopen('https://httpbin.org/get').read()验证基础网络连通性 - 执行完命令没报错但重启后仍找不到
Package Control: Install Package，检查控制台是否有reloading plugin Package Control日志，没有就说明模块根本没加载
插件装了却没反应？先确认它是否真被启用
Package Control: List Packages 是唯一可信的“已启用插件清单”，不是文件夹里有就等于在跑。很多用户以为装完就完事，结果插件根本没进启动流程。
- 手动删过
Packages/目录下的插件文件夹？那只是物理删除，Sublime 启动时仍可能尝试加载残留元数据，导致插件列表不一致甚至崩溃 - 插件名大小写敏感：
SideBarEnhancements和sidebarenhancements是两个不同条目，命令面板里输错一个字母就搜不到 - 某些插件（如
LSP类）依赖 Python 环境或额外 CLI 工具，装完不配置settings - user文件，状态栏也不会显示任何提示 - 如果列表里压根没出现刚装的插件，先禁用再启用一次：
Package Control: Disable Package→ 输入名字 →Package Control: Enable Package
卸载插件不能删文件夹，但清缓存得动手
用 Package Control: Remove Package 卸载后，插件文件虽被移除，但 Sublime 的缓存和状态快照可能还留着，下次启动时容易“复活”或引发冲突。
- Windows：进
%LOCALAPPDATA%\Sublime Text\Cache\，按插件关键词（如pyright、sublimelinter）搜索并删整个匹配文件夹 - macOS：除了 Cache，还要检查
~/Library/Saved Application State/com.sublimetext.4/，这里会偷偷保存禁用/卸载状态，删掉对应子目录 - Linux：清空
~/.cache/sublime-text/安全且必要，重启后自动重建，不影响其他设置 - 特别注意：卸载后若发现插件图标还在侧边栏或快捷键仍有效，大概率是缓存没清干净，不是卸载失败
禁用比卸载更常用，但得知道它怎么“消失”的
禁用插件本质是让 Sublime 启动时不 import 对应模块，内存占用降下来，启动变快，而且随时可恢复——但它在 List Packages 里彻底隐身，这点常被忽略。
- 禁用后插件的
Preferences → Package Settings菜单项依然存在，但点开会报“no settings file”，这是正常现象 - 禁用不影响插件的物理文件位置，所以重装 Sublime 时只要保留
Installed Packages/目录，再用Enable Package就能秒恢复 - 多个插件冲突时（比如两个都改
Ctrl+Shift+P行为），逐个禁用比反复卸载重装高效得多 - 别指望禁用能解决所有性能问题：有些插件（如实时语法检查类）即使禁用，其后台进程可能仍在运行，得看具体插件文档是否提供开关项
真正麻烦的从来不是“怎么装”，而是装完之后谁在加载、谁在缓存、谁在后台占资源——这些细节不摸清，插件越多，编辑器越脆。
