01 · 产品定位与设计哲学

Mole 不是“把常见 rm -rf 放进脚本”，而是把 macOS 维护任务包装成可解释、可预览、可追溯的受控操作。

六个命令，其实是三类问题

类型	命令	核心问题
空间回收	clean、uninstall、purge、installer	找什么、能否删、如何恢复
运行维护	optimize	哪项维护适用、是否执行成功
观察诊断	analyze、status	如何低成本持续呈现真实状态

它们共享一个产品原则：默认行为应当比手工命令更容易理解，也更难造成灾难。所以项目大量代码并不负责发现垃圾，而是负责拒绝危险输入、展示将发生什么、在执行后留下证据。

安全不是单个函数

Mole 的安全设计更接近“防御纵深”：

1. 命令层限制参数和模式，例如卸载默认走 Trash，永久删除显式开启。
2. 发现层避开保护目录、运行中的应用和云同步空间。
3. 策略层结合关键路径、应用身份和用户白名单。
4. 删除汇点重新验证绝对路径、祖先目录、所有权与符号链接。
5. 日志层记录接受、拒绝、失败和删除证据。

因此，safe_remove 不是安全体系的全部；它只是不可逆动作前最重要的一道门。

保守失败比“尽力完成”重要

代码中反复出现 fail-closed：

• 路径大小无法计算时记为 unknown，不伪装为 0。
• Trash 失败时不自动降级为永久删除。
• 高权限路径的祖先属性无法读取时拒绝，而不是猜测安全。
• 下载到的二进制校验失败时中止，不转去未经验证的构建路径。
• Optimize 任务必须报告明确结果，漏报本身就是错误。

这些选择可能牺牲“清得更多”或“更新总能成功”，但维护工具一旦误判，代价远高于漏掉一份缓存。

兼容性是一等约束

Shell 侧维持 Bash 3.2 兼容，因此注册表常用对齐数组而不是关联数组；系统能力通过 command -v、版本检测和有界超时渐进增强。Go 侧承担需要持续刷新、键盘交互、并发扫描的 TUI，同时输出 JSON 以适配脚本。

这不是“旧代码 + 新代码”的偶然混搭，而是清楚的职责分工：Shell 更适合编排 macOS 命令和文件规则，Go 更适合长期运行的状态机与高并发采集。

关键源码索引

• README.md：用户侧能力与命令面。
• lib/core/file_ops.sh：文件操作安全汇点。
• cmd/analyze/main.go：Analyze 的 CLI/TUI 双入口。
• cmd/status/main.go：Status 的输出模式与刷新循环。

下一章把这些能力放回目录和依赖图中，观察哪些模块能产生副作用，哪些只能提供策略。