Mac 的空间快满时，我最先看到的往往不是几个明确的“大文件”，而是一堆散在不同工具目录里的缓存、构建产物和本地数据。
对开发环境来说，目录大不等于可以直接删除。node_modules 和 Cargo target 通常可以重建，Docker volume 里却可能放着数据库；Xcode DerivedData 清掉后会重新生成，但下一次构建要付出时间。真正需要判断的是：它属于什么工具，能不能恢复，删除后会影响什么。
开发环境里常见的占用
- Xcode：DerivedData、Archives、模拟器数据和构建产物。
- Docker：镜像、容器、volume、build cache 和 Docker Desktop 数据。
- Node.js / 前端项目：
node_modules、.next/cache、dist、build，以及 pnpm、npm、yarn 的缓存。 - Rust：项目
target/、Cargo registry、git checkout 和编译缓存。 - Java / JVM：Gradle、Maven 的依赖缓存和构建目录。
- Python：
.venv、pip cache、__pycache__和 tox 环境。 - IDE 与编辑器：VS Code、Cursor、JetBrains、Android Studio 的索引、日志和语言服务数据。
- AI 工具：本地模型、索引、会话状态、日志和临时文件。
这些数据不会集中在同一个位置，macOS 的存储页面也很难解释每个目录和当前项目的关系。最后看到的通常只是“磁盘快满了”，而不是一份可以直接执行的清理清单。
我为什么不想做黑盒一键清理
开发缓存并不等于垃圾。
同样是 20 GB，占用的含义可能完全不同：一份可重新下载的依赖缓存、一组正在使用的 Docker 数据、一个已经归档但仍需要保留的构建结果。只按大小排序，很容易把“释放空间”变成“破坏本地环境”。
我更愿意把扫描结果分成三类：
| 等级 | 含义 |
|---|---|
| Safe | 可重建的缓存或临时数据，通常可以清理 |
| Caution | 可能影响当前开发流程，需要先确认 |
| Danger | 可能包含重要数据，默认不应选择 |
这个分类不能替用户做决定，但至少能把风险放在点击删除之前。
一个更稳的清理顺序
我认为开发者清理工具至少要完成三件事：
- 扫描：找到开发缓存、构建产物、包管理器缓存、IDE、Docker 和 Xcode 数据。
- 解释：说明目录来自哪个工具，是否可重建，删除后可能发生什么。
- 预览：在真正删除前展示范围、体积和风险等级，让用户最后确认。
我正在做的 Zen Clear，就是从这个顺序开始的。它面对的不是所有 macOS 用户，而是磁盘里长期堆着多个项目、工具链和本地环境的开发者。
我把本地扫描作为产品边界：清理判断应尽量在用户自己的 Mac 上完成，而不是先把文件内容和扫描结果交给云端分析。这个选择让产品更克制，也意味着工具必须把本地规则、风险解释和恢复边界做得更清楚。
产品页面：rustzen.dev
反馈邮箱：support@rustzen.dev
我更希望第一次使用 Zen Clear 的人先把它当成一次开发磁盘体检。先确认空间被什么占用，再决定哪些东西值得清理。