Mole CLI 还是 Mole Mac 版，应该选哪个

Mole 有两个独立程序。mo 是通过 Homebrew 安装、采用 GPL-3.0 的免费开源命令行工具。Mole for Mac 是带五个页面与菜单栏入口的付费原生应用。

它们不是试用版与专业版，而是两套实现，工作范围有重叠，磁盘上也共享少量数据。选择其中一个，不会阻止以后使用另一个。下面说明怎样按自己的工作方式选择，以及同时保留两者时会发生什么。

两者共享什么

命令行版五项主要命令与应用五个页面直接对应：mo clean、mo uninstall、mo optimize、mo analyze 和 mo status，分别对应「清理」「软件」「优化」「分析」与「状态」。

两边的类别很容易互相识别，包括重叠的用户、开发工具、浏览器和系统缓存，应用清单与残留发现，磁盘分析和健康指标。不过，两者实现与精确候选清单并不完全相同。

两边扫描都免费。Mac 应用只对破坏性操作收费，每项破坏性工具在需要授权前都可以执行两次，因此可以在同一台 Mac 上免费比较应用与命令行版的扫描结果。

更有意思的重叠发生在磁盘上。两者都会读写 ~/.config/mole/whitelist 与 ~/.config/mole/whitelist_optimize，也都会把操作追加到 ~/Library/Logs/mole/operations.log。在一个界面保护的缓存，另一个也会保护；任一程序执行的删除都会进入同一份记录。

两个程序运行时不知道彼此存在，却也不是完全独立。

只有终端能做什么

命令行版有三套较大工作流没有对应的应用页面。mo history、mo update、mo completion 和 mo remove 等辅助命令则属于终端管理，并不是新的维护表面。

mo purge

它会扫描项目目录，并提供删除大型构建产物的选择。目标范围很广，包括 target、build、dist、.next、DerivedData、__pycache__、coverage 等约三十多类，也包含软件包管理器必须重新下载的依赖目录。

Purge 会永久删除，不经过废纸篓。最近七天有改动的项目会标为近期并默认不选。它能直接从开发电脑回收几十 GB，也是最应该先运行 --dry-run 的命令。

mo installer

它会从下载、桌面、Homebrew 缓存、iCloud 和邮件中扫描 DMG、PKG 与归档安装包，并标注每项来源。

mo touchid

它为 sudo 配置 Touch ID，属于 shell 配置任务，不是清理。

除了命令本身，终端还有图形界面无法替代的三种能力。每个破坏性命令都支持 --dry-run，准确打印将要移除的内容，同时不执行删除。mo analyze、mo status 和 mo history 支持 --json，mo status 在输出被管道接收时还会自动切换到 JSON，因此健康检查可以进入脚本。

只读与结构化输出也能通过 SSH、在无界面 Mac 或脚本中运行。定时删除仍需要明确的非交互政策，交互确认界面不会因为由 cron 启动就自动变安全。

只有 Mac 应用能做什么

应用增加的内容主要集中在终端不擅长的两件事：持续显示与特权系统控制。

显示方面，「分析」提供可下钻矩形树图，「状态」提供带趋势线和可置顶进程的实时卡片面板，菜单栏 HUD 则会在使用其他应用时持续展示 CPU、内存和网络。「卸载」会在移动任何内容前展示带路径、所有者与大小的检查计划，普通删除进入废纸篓，不会直接永久清除。

系统控制方面，应用通过 SMJobBless 安装范围克制的 root 辅助程序，用于风扇和支持机型的电池写入。启动项管理使用另一条边界：能验证身份的 launchd 任务和受支持 Service Management 项目可以切换；无法匹配的后台项目会打开系统设置，不靠猜。

应用还提供只有常驻图形程序才合理的入口：报告实时摄像头和麦克风使用的「隐私检查」、在支持 Mac 上把充电保持在约 75% 到 80% 的「电池养护」、防止休眠、用于擦键盘的「清洁屏幕」，以及生成只读诊断报告的「诊断」。

最大的应用专属表面，是更新其他应用。它可以发现多个更新渠道，并为 Sparkle、Homebrew cask 与 formula、Mac App Store 和 Electron 订阅源提供应用内路径。GitHub Releases 与网站元数据还能识别其他版本；无法安全验证并替换应用包时，Mole 会打开应用或厂商页面，不会自行发明另一种安装器。

授权为一次购买，两台 Mac 终身更新，有 14 天退款期，要求 macOS 14 或更高版本。两个程序都不发送遥测。

两个界面怎样共用安全规则

Mac 应用不是通过 shell 调用 mo 的包装器，而是 Swift 重新实现。两个代码库共享的是路径与安全决定，不是运行进程。

「分析」借鉴了命令行版的路径分类和并行计算经验，但拥有自己的扫描器、超时、部分结果状态、缓存和回退。因此，一边的总数可以用于交叉检查，却不承诺逐字节一致。

仓库中保持两者方向一致的原则是：命令行 parity 表示相同或更安全，不表示删除范围完全相同。应用展示的每个候选项都会先分类为默认可选、默认不勾选的仅检查项，或无论谁请求都拒绝的阻止项。命令行行为与分类产生分歧时，应用选择更窄的一侧。

mo purge 是最直观例子。移植到 Mac 应用的扫描会主动丢弃命令行版处理的所有下载依赖目录，包括 node_modules、Pods、venv 和 vendor。原因是可恢复性：编译生成的 target 可以从本地构建恢复，依赖树却需要网络，之后解析出的内容还可能与原安装不同。

应用只提供能够通过纯本地编译重建的内容，并把它们显示为默认不勾选的检查项。相同的不对称还出现在其他位置：应用在检查应用数据前要求完全磁盘访问，执行删除时重新校验每条路径，而不是只在扫描时检查，并把普通移除送进废纸篓。

所以两者不会同样激进，而且差别始终朝一个方向。命令行版回收更多，因为它假定用户会读清清单；Mac 应用回收更少，因为它假定用户希望清单本身已经足够安全。

同时运行两者

安装两者不会冲突，共享文件也让组合保持一致。在应用设置中保护缓存后，mo clean 同样会跳过。通过 mo clean --whitelist 加入路径，应用也会遵守。两个程序的删除都进入同一份日志。

有两点需要知道。程序运行时不会互相协调，所以不要同时在两边开始清理。应用刻意采用更窄范围，因此 mo clean 中出现应用从不展示的类别，是预期行为，不是缺少功能。

怎样选择

如果日常工作都在终端，希望先用 --dry-run 预览，需要 --json 进入脚本，想使用项目产物与安装包扫描，或只是不想付费，就安装命令行版。对开发电脑而言，它经常已经足够，而且它本来就应该保持免费。

如果需要磁盘地图、实时面板、风扇控制、启动项管理或第三方应用更新，或者准备替绝不会打开终端的人安装，就选择 Mac 应用。最后一种情况正是它最初出现的原因，完整故事见 Mole 的故事。

暂时无法判断时，先安装命令行版并运行 mo clean --dry-run。它不收费，也不会删除任何内容。读一遍结果，很快就能看出这台 Mac 有没有值得交给工具处理的问题，这也是安装任何清理软件前都应该先问的问题。