Package Control: Remove Package仅删除插件本体，不清理Packages/User配置、Cache缓存及同步状态，导致命令残留、CPU飙高、右键菜单仍在、重装后自动恢复；需手动删除.settings文件、keymap绑定及Cache中对应插件文件夹，并关闭所有Sublime进程后再操作。
Package Control: Remove Package 只删插件本体，不清理配置、缓存、同步状态——直接导致命令残留、CPU 飙高、右键菜单还在、重装后自动复活。
为什么卸载后命令面板还能搜到插件命令？
因为 Packages/User/ 下的 PluginName.sublime-settings 文件没删，里面可能含 key bindings 或自定义 commands。Sublime 启动时会加载这些配置，命令名就“活”在命令面板里，但实际执行时找不到对应逻辑，报 command not found。
- 打开
Preferences → Browse Packages…，进Packages/User/ - 搜索插件名（如
lsp、gitgutter、sidebar_enhancements），删掉所有匹配的.sublime-settings文件 - 顺手打开
Default (Windows).sublime-keymap（或对应系统文件），全局搜索插件关键词，删掉整块含"command": "xxx"的键位绑定
Cache 目录不清，LSP 类插件照常吃 CPU
像 pyright、texlab、LSP-pyright 这类语言服务器插件，卸载后仍会在 Cache 目录下留着索引、socket 文件和编译缓存。Sublime 重启时可能自动拉起它们，CPU 持续 100%，甚至卡死。
- Windows：删
%LOCALAPPDATA%\Sublime Text\Cache\下含插件关键词的整个文件夹（如pyright） - macOS：删
~/Library/Caches/Sublime Text/和~/Library/Saved Application State/com.sublimetext.4/（后者会偷偷恢复插件状态） - Linux：
rm -rf ~/.cache/sublime-text/*最省事，安全，重启后自动重建
插件没出现在 Remove Package 列表里？你可能是手动安装的
从 GitHub 下载 ZIP 解压拖进 Packages、用软链接（symlink）挂载、或曾用旧版 Sublime 安装过——这些方式都绕过了 Package Control，所以命令面板里搜不到、列表里也看不到。
一款AI工具，主要用于面向CTF的ZIP破解与恢复，使用捆绑的ZipCracker引擎。当Codex或OpenClaw需要在授权情况下分析或恢复受加密ZIP时使用，适合需要提升相关任务效率的用户。
- 先确认真实
Packages路径：Preferences → Browse Packages…，别误入Sublime Text 3目录而你用的是 Text 4 - 在正确路径下，找同名文件夹（如
SideBarEnhancements），**整文件夹删除**，不要只删 .py 文件——残留的__pycache__或.pyc仍可能被加载 - 再往上一级进
Installed Packages/，搜PluginName.sublime-package并删掉（尤其反复装卸过的插件，这里极易残留）
删之前不关进程，文件会被锁住、删不干净、重启后“复活”
很多人删完 Packages/GitGutter，重启发现插件又回来了，或者提示“文件正在使用”——根本不是权限问题，而是 sublime_text.exe（Windows）、Sublime Text（macOS）或 subl（Linux）还在后台跑着，锁住了缓存和配置文件。
- Windows：任务管理器 → 搜索
sublime_text.exe和subl.exe→ 全部结束 - macOS：活动监视器 → 搜索
Sublime Text→ 强制退出所有匹配项 - Linux：终端运行
pkill -f "sublime_text"或pkill -f "subl" - 删完务必确认
Packages/User/Package Control.sublime-settings已消失，否则同步账号会把旧插件全拉回来
真正让插件“阴魂不散”的从来不是代码本身，而是 Packages/User/ 里的配置、Cache/ 里的索引、以及没登出的同步账号——这三处不碰，卸载就等于没卸。
