技术解读

以下内容由 GitRead 中文社区 编辑团队基于项目 README 与官方资料整理, 结合中文开发者的常见使用场景补充技术选型建议。具体以项目官方文档为准。

PureMac:把「清理」从黑盒订阅,变成可审计的 Swift 代码

项目背景与痛点

macOS 上的清理工具长期处于一个尴尬位置:需求真实存在,供给却高度商业化。CleanMyMac 这类产品把「扫描—推荐—删除」包装成一个漂亮的单向流程,用户看到的是一句「可释放 12.4 GB」,看不到的是它到底删了哪些路径、依据什么规则、有没有把不该动的东西塞进清理队列。订阅制叠加遥测上报,让这件事从工具变成了信任透支。

对开发者而言,痛点更具体:Xcode 的 DerivedData、Archives、iOS DeviceSupport 动辄吃掉几十 GB;Homebrew 的下载缓存、旧版本 cellar 常年无人清理;~/Library/Caches 里散落着各种 Electron 应用的几百 MB 垃圾。手动 rm -rf 不是不行,但路径记不住、误删风险高、也无法定期执行。

PureMac 的定位就卡在这个缝隙里:MIT 协议、零遥测、原生 SwiftUI。它不试图做「全能系统优化大师」,而是把清理这件事拆成可读的规则和可审计的代码。这个取舍本身,比功能列表更值得讨论。

核心技术揭秘

从公开信息推断,PureMac 的架构并不复杂,但每一层都有明确的职责边界。它的技术栈是标准的现代 macOS 组合:SwiftUI 做界面,Swift Concurrency 做并行扫描,FileManager 做文件系统遍历,launchd / SMAppService 做定时调度。

graph TD A[SwiftUI 主界面] --> B[权限与安全书签层] B --> C{"是否具备全盘访问?"} C -->|"否"| D[引导授权-拒绝则降级扫描] C -->|"是"| E[扫描调度器] E --> F[Scanner 协议-声明式规则] F --> G[Xcode 派生数据] F --> H[Homebrew 缓存] F --> I[系统与应用缓存] G --> J[风险分级与白名单校验] H --> J I --> J J --> K[生成清理计划与预估空间] K --> L[用户确认] L --> M[执行删除-优先移入废纸篓] M --> N[日志-统计与下次调度]

几个关键设计点:

1. 权限是架构的第一道门。 macOS 的 TCC 机制决定了清理工具必须拿到全盘访问(Full Disk Access),否则连 ~/Library/Containers 都读不全。PureMac 把权限检测放在流程最前端,授权失败时降级为「只扫用户可读目录」,而不是直接崩溃——这是务实的做法,也解释了为什么它大概率不以 App Sandbox 形式分发:沙盒和全盘清理在物理上互斥。

2. Scanner 抽象 + 声明式规则。 每个清理目标(Xcode、Homebrew、系统缓存)对应一个实现统一协议的扫描器,规则以路径模板、匹配模式、风险等级的形式描述。好处是可扩展:新增一个清理项不需要改 UI 和调度逻辑,只需追加规则。这也是开源项目能靠社区维护规则库的前提。

3. 先计划、后执行的两段式。 扫描产出的是「清理计划」而非直接删除动作,计划包含路径、体积、风险标签,等用户确认后才进入执行阶段。执行层优先走废纸篓回收(NSWorkspace.recycle),而非不可逆的 unlink。这个设计把误删的代价从「灾难」降到了「后悔」。

4. 定时清理依赖系统级调度。 自动清理不可能靠 App 常驻定时器实现——用户关掉窗口就失效了。合理实现是注册 LaunchAgent,由系统在后台唤起执行扫描与清理,这也是它敢承诺「scheduled auto-cleaning」的技术基础。

5. 零遥测 = 无网络能力。 这不是一句营销口号,而是可以被验证的工程约束:不引入分析 SDK、不申请网络 entitlement,代码里没有上报端点。对一个要读你整个家目录的程序来说,这是最有分量的承诺。

功能亮点与差异

相比商业竞品,PureMac 的差异化不在功能数量,而在三个「反直觉」的选择:

  • 专项优于泛化。 它对 Xcode 和 Homebrew 的处理是有针对性的,而不是笼统的「开发者缓存」。这恰恰是目标用户最痛的部分。
  • 可审计优于智能。 没有花哨的「智能推荐算法」,规则是明文可读的。你完全可以打开仓库,确认某条规则不会碰你的 ~/Documents。
  • MIT 优于免费。 免费但闭源的工具,你永远在赌作者的人品;MIT 意味着最坏情况下你可以 fork 自己维护。

对比之下,它的功能面确实窄:没有大文件可视化、没有卸载残留追踪、没有恶意软件扫描。但对开发者用户来说,这些大多不是刚需。

应用场景与落地建议

适合的场景:开发机日常维护、CI/构建机的 Xcode 缓存治理、多人共用 Mac 的环境清理。这类场景的共同点是缓存膨胀快、清理收益明确、不涉及敏感用户数据。

落地时要注意:

  1. 先备份再试用。 首次运行前确保 Time Machine 有快照,尤其是要授予全盘访问权限时。
  2. 只清缓存,不动用户数据。 建议把清理范围锁定在 DerivedData、Archives、Homebrew cache 和 ~/Library/Caches,避开 Containers 与 Application Support。
  3. CI 环境谨慎开启自动清理。 定时任务若在构建中途触发,可能删掉正在使用的派生数据。更稳妥的做法是显式调用,而非依赖调度。
  4. 关注规则更新。 Xcode 和 Homebrew 的目录结构会随版本变动,规则库需要跟着维护,长期不更新的规则可能失效或误伤。

综合评价

优点:定位清晰,代码可审计,零遥测的工程约束真实可信;对开发者缓存的覆盖精准;采用两段式清理与废纸篓兜底,误删风险控制得当;MIT 协议给了长期使用的底气。

不足:功能面窄,无法替代完整的系统维护套件;依赖全盘访问权限,天然与沙盒模型冲突,分发和公证上会有摩擦;规则库的准确度完全取决于维护活跃度,属于典型的「社区项目风险」;缺少对清理结果的深度可视化与回滚机制,撤销仍依赖用户自己去废纸篓捞。

一句话总结:它不是 CleanMyMac 的平替,而是一个更小、更透明、更适合开发者的清理原语。 如果你在意「这个工具到底动了我的什么」,PureMac 值得放进工具箱;如果你要的是一键搞定所有系统垃圾,它还不够。

关于

GitHub 原始描述(英文)

Free, open-source macOS cleaner. CleanMyMac alternative with zero telemetry. Native SwiftUI, scheduled auto-cleaning, Xcode/Homebrew/system cache cleanup. MIT licensed.

描述取自 GitHub 官方 API,保持仓库作者书写的原文。

简要分析

热度分
8734
价值分
4817
活跃状态
活跃

语言占比

JavaScript
Ruby
Shell
Swift

Release