package control 卸载插件仅删除主目录和 .sublime-package 文件，不清理 packages/user/ 下的配置、cache 下的语言服务器索引及同步状态，需手动清除三处残留并退出所有进程才能彻底卸载。
Package Control 卸载只删代码，不删配置和缓存
用 Package Control: Remove Package 看似干净，实则只移除插件主目录和 Installed Packages 下的 PluginName.sublime-package 文件。它完全不管你在 Packages/User/ 里手动写的 GitGutter.sublime-settings，也不清 Cache 目录下语言服务器（比如 pyright）生成的索引——结果就是重启后 CPU 还飙高、右键菜单还有选项、命令面板仍能搜到命令但一执行就报 command not found。
- 按
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS），输入Package Control: Remove Package回车 - 在弹出列表中选中插件名（支持模糊搜索，输
git就能定位GitGutter） - 确认后，插件本体被删，但
Packages/User/GitGutter.sublime-settings和%LOCALAPPDATA%\Sublime Text\Cache\pyright\这类文件夹依然存在
手动删插件前必须关死所有 Sublime 进程
很多人删完 Packages/GitGutter 文件夹，重启发现插件“复活”了，或者提示“文件正在使用”——根本不是权限问题，而是 sublime_text.exe（Windows）、Sublime Text（macOS）或 subl（Linux）还在后台跑着。LSP 插件、同步服务、剪贴板监听都可能让进程常驻，锁住缓存和配置文件。
- Windows：打开任务管理器 → 搜索
sublime_text.exe和subl.exe→ 全部结束任务 - macOS：打开「活动监视器」→ 搜索
Sublime Text→ 强制退出所有匹配项 - Linux：终端运行
pkill -f "sublime_text"或pkill -f "subl"
三处残留不清理，卸载等于没卸
真正让插件“阴魂不散”的是这三处：用户配置、缓存索引、同步状态。哪怕插件本体已删，只要 Packages/User/ 里还留着带 key bindings 的配置，命令面板就还能搜出命令；只要 Cache/ 里还有 texlab 文件夹，LSP 就可能自动拉起并吃满 CPU；只要没登出账号，重装后 Package Control 会直接从云端恢复插件列表。
- 进
Packages/User/，搜插件名（如lsp、side_bar），删掉对应.sublime-settings文件 - 去缓存目录：
%LOCALAPPDATA%\Sublime Text\Cache\（Win）、~/Library/Caches/Sublime Text/（macOS）、~/.cache/sublime-text/（Linux），删掉含插件关键词的整个文件夹 - 运行
subl --sync-logout（确保subl在 PATH 中），或菜单栏点Sublime Text → Preferences → Sync Settings → Logout
重装前务必确认 Packages/User/Package Control.sublime-settings 已消失
这个文件是“插件复活”的关键开关。它不仅记录你装过哪些插件，还会在首次启动时触发自动重装逻辑。哪怕你删光了 Packages 目录，只要它还在，Package Control 就可能重建整个插件生态——包括你早想扔掉的 SideBarEnhancements 和 LSP。
- 删插件后，别急着重启；先检查
Packages/User/是否还存在Package Control.sublime-settings - 如果存在，打开它，搜索
"installed_packages"字段，手动清空数组内容，或直接删掉该文件 - 重装 Sublime 后，首次启动时等几秒，看右下角是否弹出
Installing Package Control…—— 如果出现，说明旧状态已被切断
最麻烦的从来不是删插件本身，而是那些藏在 User 配置里的一行键位绑定、缓存目录里一个没命名的 00123456789 文件夹、还有你以为登出过的同步账号。这些地方不动，卸载就只是给尸体换件衣服。
