打开Mac的“系统设置→通用→储存空间”，很多用户会看到一块灰色的“系统数据”（System Data，旧版本称“其他”）——50GB、80GB，甚至100GB以上。更令人困惑的是，macOS并不会像展示照片、应用、文稿那样把“系统数据”里面的内容列清楚。
这个现象并非系统“吃掉”了硬盘，而是APFS容器结构、快照机制与系统缓存策略共同作用的结果。本文将从文件系统层面拆解“系统数据”的技术构成，分析其膨胀的根本原因，并给出从手动到工具的完整清理方案。
一、APFS：理解“系统数据”的文件系统基础
要理解“系统数据”为什么存在、为什么难以清理，首先需要理解macOS底层的文件系统——Apple File System（APFS） 。
APFS是Apple于2017年在macOS High Sierra中引入的专有文件系统，针对闪存/SSD存储进行了优化，具备强加密、写入时拷贝（copy-on-write）元数据、空间共享、文件和目录克隆、快照（snapshots）等核心特性。
1.1 空间共享：APFS的“柔性”存储模型
APFS采用按需分配存储空间的机制。当单个APFS容器包含多个宗卷时，容器的可用空间在所有宗卷间共享，可按需分配到任意单独的宗卷。
在macOS 10.15或更高版本中，启动Mac的APFS容器至少包含五个宗卷：
| 宗卷 | 用途 | 是否对用户可见 |
|---|---|---|
| 预启动宗卷（Preboot） | 包含启动每个系统宗卷所需的数据 | 隐藏 |
| VM宗卷 | 存储加密的交换文件（swap files） | 隐藏 |
| 恢复宗卷（Recovery） | 用于在recoveryOS中启动 | 隐藏 |
| 系统宗卷（System） | 包含macOS系统文件和原生应用 | 可见但只读 |
| 数据宗卷（Data） | 包含用户数据、安装的应用、可写目录 | 可见 |
系统宗卷在macOS 11或更高版本中通过快照捕获，操作系统从系统宗卷的快照启动，而非直接从可变系统宗卷的只读装载启动。系统宗卷默认不允许任何进程写入，甚至连Apple系统进程也不能写入——这解释了为什么macOS的系统文件本身不会“变脏”，也解释了为什么“系统数据”中不包含操作系统核心文件。
空间共享的设计意味着：用户看到的“可用空间”是容器总大小减去所有宗卷已用空间的总和。当一个宗卷（如数据宗卷）产生大量缓存和临时文件时，整个容器的可用空间都会减少——但用户无法在访达中直接看到这些文件散布在哪些具体路径下。
1.2 快照机制：APFS的“时间旅行”代价
APFS快照是宗卷在某一时刻的完整、只读、可挂载的表现形式。快照本身在创建时不占用额外空间，但一旦快照创建后原有数据被修改或删除，APFS必须保留原始数据块，因为这些块被快照引用——这些块无法被回收。
Time Machine利用APFS快照在本地保存文件变更记录。当Mac开启了Time Machine但长时间未连接备份盘时，macOS会将文件变更以APFS快照形式暂存在本地，上限可达磁盘容量的80%。实测案例中，一台256GB的MacBook Air通过清理本地快照，系统数据从97GB降至22GB，释放了75GB空间。
快照机制的核心矛盾在于：它为用户提供了数据恢复能力，但代价是大量存储空间被“冻结”——即便用户删除了文件，只要快照存在，这些文件的数据块就不会被释放。这正是“系统数据”异常膨胀的最常见技术原因。
二、“系统数据”的真实构成：一个“归类桶”的技术解剖
Apple官方对“系统数据”的定义是：一个总括分类，用于统计所有无法归入更具体类别（如应用程序、文稿、音乐等）的Apple和第三方文件。
| 类别 | 典型路径 | 典型大小 | 可清理性 |
|---|---|---|---|
| Time Machine本地快照 | APFS快照（diskutil apfs listSnapshots /） | 30-80GB | ✅ 可安全清理 |
| 应用缓存 | ~/Library/Caches/ | 5-20GB | ✅ 可安全清理 |
| 系统缓存 | /Library/Caches/ | 2-10GB | ✅ 可安全清理 |
| 日志文件 | ~/Library/Logs/、/var/log/ | 数GB | ✅ 可安全清理 |
| iOS设备备份 | ~/Library/Application Support/MobileSync/Backup/ | 10-100GB+ | ✅ 可选保留 |
| 应用残留 | ~/Library/Application Support/、~/Library/Preferences/ | 2-5GB | ✅ 可清理 |
| Xcode开发缓存 | ~/Library/Developer/Xcode/DerivedData/ | 5-50GB | ✅ 可清理 |
| 虚拟机镜像 | ~/*.vmwarevm/、~/*.qcow2 | 20-200GB | ⚠️ 需确认状态 |
| 系统必要文件 | 内核缓存、字体缓存、Spotlight索引 | 10-15% | ⚠️ 可清理但会重建 |
关键结论：系统数据中80%以上是可以安全清理的。之所以很多人不敢动，是因为“系统数据”这个名字听起来像系统核心文件，但实际上它里面装的大部分是临时文件和历史残留。
- 新Mac/刚重装系统：10-18GB（纯净系统的底数）
- 正常使用半年到一年：20-40GB（缓存、日志、快照的自然累积）
- 重度使用1-2年：40-80GB（Xcode、Docker、Adobe等大型工具贡献了大量增量）
- 超过100GB：异常，说明有“空间泄漏”——大概率是本地快照堆积或孤儿缓存未回收
三、系统数据主要来源的技术分析
3.1 缓存：性能与空间的取舍
缓存是“系统数据”最常见的来源之一。macOS鼓励应用采用积极缓存（aggressive caching） 策略以最大化应用性能。
应用缓存应放置在~/Library/Caches/下以应用Bundle ID命名的子目录中。应用不应依赖缓存文件的存在——这意味着缓存文件可以被安全删除，应用会在需要时自动重建。
但问题在于：
- 系统不会自动清理
Caches目录 - 长期积累后，浏览器缓存、应用缓存、系统缓存可能占用数GB甚至更多空间
- Xcode的DerivedData目录动辄数十GB
共享缓存机制（如dyld共享缓存）将动态库缓存加载到内存中以提高加载效率，但这些缓存也会在磁盘上留下痕迹。
3.2 日志：Apple System Log的技术细节
macOS的日志系统基于Apple System Log（ASL） 。ASL文件由80字节固定长度的文件头部和日志记录组成。日志通过OSLog API写入ASL设施，可在Console.app中查看。
日志记录了系统和应用运行过程中的事件。应用崩溃、系统报错、后台服务运行时都会产生日志。普通用户几乎不会主动查看这些文件，但长期积累后也会占用相当空间。清理日志一般不影响日常使用，但如果近期遇到软件崩溃或需要售后排查，建议暂时保留相关日志。
3.3 应用残留：macOS卸载机制的系统性缺陷
在macOS上卸载软件与Windows存在本质差异。macOS没有控制面板和注册表机制，用户将.app文件拖入废纸篓后，系统不会自动清理该应用在~/Library目录下产生的关联数据。
.app文件实际上是一个文件夹（Application Bundle），里面装着主程序、资源文件、框架等。拖进废纸篓删除的只有这个包体。应用在运行期间产生的数据——缓存、偏好设置、支持文件、日志、沙盒数据——散布在以下目录中：
| 路径 | 内容类型 |
|---|---|
~/Library/Caches/ | 应用运行时缓存 |
~/Library/Preferences/ | 偏好配置文件（.plist） |
~/Library/Application Support/ | 应用支撑数据 |
~/Library/Containers/ | 沙盒应用容器 |
~/Library/Logs/ | 应用日志 |
/Library/LaunchAgents/ | 用户启动代理 |
/Library/LaunchDaemons/ | 系统守护进程 |
这是macOS沙盒与权限隔离设计导致的必然结果，并非系统Bug。App Store下载的应用因沙盒限制，大部分数据被限制在~/Library/Containers/内，残留较少；但从官网下载的应用权限更高，残留可能分布在多个目录中。
手动清理这些残留的难点在于：部分文件名不直接包含应用名（以Bundle ID如com.company.appname命名），容易遗漏。有测试显示，手动清理一次可能需要超过一小时，最后仍可能遗漏数GB的缓存目录。
3.4 系统升级的临时空间占用
macOS大版本升级是“系统数据”突然膨胀的常见诱因。一次完整的大版本升级通常需要20-30GB的临时空间用于下载安装包、创建系统快照和执行文件替换。问题在于，这些临时数据未必在升级完成后自动清空。
升级后的“系统数据”异常值可能达到50-150GB甚至更高。macOS 26 Tahoe（Apple Silicon专属）的基础系统占用约20-25GB，升级所需临时空间超过30GB。
四、清理方案：从手动到工具化的技术路径
4.1 手动清理：技术门槛与风险
手动清理“系统数据”需要用户熟悉macOS目录结构，并能准确判断文件归属。以下是主要的手动操作路径：
bash
# 查看本地快照
tmutil listlocalsnapshots /
# 删除所有本地快照
sudo tmutil deletelocalsnapshots /
bash
# 删除无效模拟器
xcrun simctl delete unavailable
# 查看DerivedData大小
du -sh ~/Library/Developer/Xcode/DerivedData/
iOS设备备份清理：在Finder中进入设备管理，查看“管理备份”，删除不再需要的旧备份。
手动清理缓存和日志：
- 进入
~/Library/Caches/，删除对应应用的同名缓存文件夹 - 进入
~/Library/Logs/，删除专属日志文件 - 进入
~/Library/Preferences/，删除以应用名或开发商ID命名的.plist文件 - 进入
~/Library/Application Support/，删除对应厂商文件夹
- 部分文件以Bundle ID命名，不直接包含应用名，容易遗漏
- 某些目录下的文件缺乏明确的归属标识，误删可能影响其他软件
- 文件数量多时耗时较长
4.2 工具化清理：BuhoCleaner的技术实现
BuhoCleaner由布霍科技（Dr.Buho）开发，团队成立于2020年。产品支持macOS 10.10及以上版本，原生兼容Intel与Apple Silicon（M1-M5）芯片。
从技术实现角度看，BuhoCleaner的核心机制包括：
（1）规则驱动的垃圾扫描引擎
BuhoCleaner的垃圾文件扫描模块会自动定位系统缓存（/Library/Caches/）、用户缓存（~/Library/Caches/）、系统日志（/Library/Logs/）、用户日志（~/Library/Logs/）、浏览器缓存、DMG安装包残留和废纸篓内容。扫描完成后按类别（系统缓存/应用缓存/日志/DMG/下载项等）清晰展示，用户可逐项判断后再决定删除。
智能识别机制确保工具不会触碰系统核心目录与用户个人资料。这种设计本质上是将文件系统路径映射为用户可理解的语义类别——~/Library/Caches/com.apple.Safari/被展示为“Safari浏览器缓存”，降低了操作门槛的同时保留了可控性。
（2）基于Bundle ID的应用深度卸载
BuhoCleaner的卸载器通过以下技术路径实现深度卸载：
- 扫描
/Applications/和~/Applications/目录，获取已安装应用的Bundle ID - 根据Bundle ID在
~/Library/Caches/、~/Library/Preferences/、~/Library/Application Support/、~/Library/Containers/、~/Library/Logs/等多个目录中匹配并列出所有关联文件 - 将应用本体与所有关联残留纳入同一卸载流程，一次性完成主程序+缓存+配置+后台服务的彻底删除
这种方式将原本需要手动翻查6个以上隐藏目录的操作压缩为一次点击，且避免了因Bundle ID命名规则不熟悉而导致的遗漏。
（3）MD5内容哈希的重复文件检测
BuhoCleaner采用MD5内容哈希算法进行文件比对——计算每个文件的MD5值，哈希值相同的即为内容完全一致的重复文件。这种基于内容而非基于文件名的匹配方式，从根本上杜绝了“同名不同内容误删”或“同内容不同名漏删”的问题。
（4）大文件定位与磁盘空间可视化
大文件清理功能按视频、文档、DMG、压缩包自动分类，支持一键列出全盘50MB以上的文件。磁盘空间分析器以可视化形式展示磁盘占用情况，帮助用户快速定位空间占用最大的文件夹。
五、总结：系统数据清理的技术原则
综合以上分析，处理Mac“系统数据”膨胀问题应遵循以下技术原则：
1. 先诊断，后清理。 使用tmutil listlocalsnapshots /检查本地快照，使用du -sh ~/Library/Caches/*等命令定位大缓存目录，明确空间去向后再采取行动。
2. 区分可清理与不可清理。 系统数据中80%以上是可清理的临时文件和历史残留。但/System/Library/下的任何内容、不熟悉的内核扩展（kext）文件、标注为“系统”且来源不明的文件不应手动删除。
3. 工具化优于手动操作。 对于不熟悉macOS目录结构和Bundle ID命名规则的用户，使用清理工具可以将清理时间从2-3小时压缩到10-15分钟，且覆盖面更全。BuhoCleaner等工具通过规则引擎、Bundle ID匹配和MD5哈希等技术手段，在降低操作门槛的同时保持了清理的彻底性。
4. 系统数据不是越小越好。 macOS需要一定的缓存和日志空间来维持正常运行。健康的做法是：当磁盘空间紧张、系统数据明显异常变大、或软件卸载后空间没有释放时，再有针对性地处理。
“系统数据”膨胀是APFS设计哲学的自然副产品——空间共享带来了灵活性，快照机制提供了数据保护，但代价是空间占用的不透明性。理解这一技术本质，是安全、高效管理系统数据的第一步。
