macOS系统数据爆满？用du与find命令彻底清理存储空间

我手里这台 512GB 的 MacBook Pro，某天打开「系统设置 → 通用 → 存储空间」，一眼看到「系统数据」后面跟着 250GB 的数值，整个人的第一反应都是：完了，这机器是不是废了？很多人遇到这个数字，第一想法就是重装系统，但折腾一圈之后往往发现，系统数据不但没瘦下来，反而因为备份恢复、iCloud 同步变得更臃肿。

macOS 里的「系统数据」从来不是一个真正意义上的文件夹，而是系统把所有不好归类的文件统一塞进的一个统计桶。想对付它，靠肉眼在访达里翻是没有用的，得用命令把空间账目算清楚。这篇文章就两把钥匙：一条du命令用来定位目录级占用，一条find命令用来找出所有超大文件。只要学会这两条命令，250GB 的「系统数据」也能被拆解得明明白白，该删的删，该留的留。

这套方法我这两年帮朋友处理过不下十台存储告急的 Mac，覆盖从 Intel 到 M 系列芯片的机型，实测有效。不管你是普通用户、开发者还是运维，只要你的 macOS 存储空间被「系统数据」压得喘不过气，这篇文章都可以直接照着抄。

1. 「系统数据」到底是个什么东西

1.1 别被名字骗了，它其实是一个「分类桶」

从 macOS Ventura 开始，系统设置里的存储空间把原先的「其他」改成了「系统数据」。名称变了，含义其实差不多：凡是系统没法归类到 App、文稿、照片、影片这些明确分类里的东西，最后都会算到「系统数据」头上。

换句话讲，「系统数据」不是某一个大文件夹，而是很多很多小碎块汇总后的统称。这里面至少包括：

• 系统文件、内核缓存、字体、语音包、词典等基础资源
• App 的缓存文件、支持文件、容器数据
• 日志、崩溃报告、诊断信息
• Time Machine 在本地留下的 APFS 快照
• Docker 虚拟磁盘、虚拟机镜像、iOS 模拟器数据
• Spotlight 索引数据库、iCloud 本地缓存
• 邮件附件、微信/钉钉等 App 的本地聊天记录

所以你会发现一个很反直觉的现象：你明明没装多少大软件，但「系统数据」照样能长到几十上百 GB。因为这些数据根本不装在你以为的「应用」里，而是散落在整个数据卷的各个角落。

1.2 导致 250GB 的四个常见元凶

根据我见过的实际案例，能把「系统数据」撑到 200GB 以上的，基本逃不出下面这四个源头：

这里面最坑的其实是 Time Machine 本地快照。很多人的 Mac 从来没有外接备份盘，但 Time Machine 功能开着，系统就会在本地持续创建快照，一旦磁盘空间紧张，这些快照会优先占用「系统数据」的份额。而且你在访达里根本看不见它们，Finder 的「管理存储空间」界面也不会给你提供一键清理入口，只有命令能搞定。

搞清楚了「系统数据」的成分，下一步就轮到两条核心命令上场了。

2. 两条命令，先让空间账目水落石出

很多教程一上来就让你删缓存、删日志，但如果你连东西在哪都不知道，删什么都是猜。我的习惯永远是先定位、后处理，哪怕多花十分钟把账算清楚，也比乱删一通然后系统出问题要强得多。

2.1 第一条命令：用 du 从目录层级找大头

打开终端（访达 → 应用程序 → 实用工具 → 终端），执行这条：

sudo du -xhd 1 /System/Volumes/Data 2>/dev/null | sort -rh | head -20

先解释一下这条命令在干什么，因为理解比复制粘贴更重要。

du是 disk usage 的缩写，作用是统计目录和文件占用磁盘空间的大小。-x表示不跨文件系统，只统计当前数据卷，外接硬盘和其他 APFS 卷不会被卷进来；-d 1表示只显示一层目录深度，也就是只看数据卷根目录下每个一级目录各占多少；-h是 human-readable，输出成 GB/MB 这种人类友好的单位；2>/dev/null是把权限不足的报错全部丢弃，避免刷屏。后面的sort -rh按占用大小从大到小排序，head -20只保留前 20 行。

这里有一个很多人都会踩的坑：不要直接执行sudo du -xhd 1 /。从 macOS Catalina 开始，系统卷和数据卷是分离的，根目录/下好几个目录其实是指向数据卷的链接，直接扫根目录要么漏掉真正的数据大头，要么统计结果五花八门根本没法看。从/System/Volumes/Data这个数据卷根部开始扫，才能把用户文件、Docker、快照这些真正的「重量级选手」全部纳入统计。

如果你还停留在 macOS Mojave 或更早的版本，系统没有数据卷独立挂载这个概念，那把这命令里的路径直接换成/就行。

2.2 第二条命令：用 find 挖出所有超大文件

目录级别的统计能告诉你「哪个文件夹大」，但文件夹大不代表里面每个文件都能删。为了进一步锁定具体的文件，第二条命令上场：

sudo find /System/Volumes/Data -xdev -type f -size +500M -exec ls -lh {} \; 2>/dev/null | sort -k5 -rh | head -30

这条命令的意思是：在数据卷范围内（-xdev不跨文件系统），找出所有普通文件（-type f）、大小超过 500MB 的（-size +500M），对每个找到的文件执行ls -lh，把权限、大小、修改时间、完整路径打出来，最后按第五列（文件大小）从大到小排序，取前 30 条。

500MB 这个阈值是经验值。低于 500MB 的小文件数量太大，扫出来噪音太多；超过 500MB 的一般就是虚拟磁盘、视频素材、数据库文件这类重量级对象，重点排查价值最高。如果跑完发现没什么结果，屏幕上干干净净，可以把500M改成200M再跑一遍，覆盖范围更大。

需要提醒的是，find全盘扫描会比较慢，尤其首次运行时可能要花几分钟。加上2>/dev/null之后终端会安静很多，不会一直被「Permission denied」刷屏。等待期间去泡杯咖啡，或者先去看第一条命令的输出结果，都不耽误。

2.3 拿到输出之后怎么读，怎么顺藤摸瓜

这两条命令执行完，终端里应该会出现一份非常直观的「空间账单」。以我自己一次真实排查为例，第一条命令的典型输出长这样：

120G /System/Volumes/Data/private 85G /System/Volumes/Data/Users 35G /System/Volumes/Data/Applications 9G /System/Volumes/Data/Library ...

/private下面 120GB，明显不正常，正常的系统数据里不应有这么大的体积。于是继续深入一层：

sudo du -xhd 1 /System/Volumes/Data/private/var 2>/dev/null | sort -rh | head -20

输出里db目录占了大头，再往下追：

sudo du -xhd 1 /System/Volumes/Data/private/var/db 2>/dev/null | sort -rh | head -20

到这里基本就破案了：TimeMachine目录占了 90GB，这就是 Time Machine 在本地留下的 APFS 快照。从 90GB 到 250GB 的谜底，靠一条命令一层层追下去，水落石出。

第二条命令的输出则更直接地告诉你「哪些大文件躺在哪」。比如：

-rw------- 1 me staff 40G Mar 10 09:12 /Users/me/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw -rw-r--r-- 1 me staff 28G Feb 22 15:04 /Users/me/Library/Developer/CoreSimulator/Devices/xxxx/data/...

看到Docker.raw的路径就明白，这是 Docker 的虚拟磁盘文件；看到CoreSimulator就明白，这是 iOS 模拟器装过的系统镜像。路径、大小、修改时间都摆在眼前，哪些是长期没用的，哪些是最近刚产生的，一目了然。

读输出时有个原则要守住：不要只看文件大小就动手删，先看路径和文件名，想一想「这个路径属于谁、这个文件是干嘛的」。想不清楚就再花一分钟用ls -lh配合 Date 信息看看修改时间，或者直接去访达里按路径打开确认一下。搞清楚再删，永远比删完后悔要好。

3. 定位之后，按类型安全清理

命令只是探照灯，真正让空间回来的关键还是清理动作。这一章我把最常见的几类「系统数据大头」的清理方法逐个拆开讲，每一步都给到可以直接复制的命令。

3.1 时间机器本地快照：最容易无感膨胀的一块

如果第一条命令查出来/System/Volumes/Data/private/var/db/TimeMachine占了大量空间，那元凶基本就是 Time Machine 本地快照。

先列出当前系统里有哪些本地快照：

tmutil listlocalsnapshots /

输出大概是这种格式：

com.apple.TimeMachine.2025-01-10-083456.local com.apple.TimeMachine.2025-01-11-103456.local

这些是 APFS 文件系统给 Time Machine 做的本地快照，用来在「没有外接备份盘」时也能提供一定的时间回溯能力。问题是很多人根本没注意它开着，系统默认行为会不断创建快照，空间紧张时又没法自动全清，于是越积越多，最终全算到「系统数据」头上。

删除指定快照的命令是：

sudo tmutil deletelocalsnapshots 2025-01-10-083456

把命令里的日期字符串换成tmutil listlocalsnapshots /输出里对应的时间戳即可。如果你确定不需要保留任何本地快照，也可以逐个把所有快照都删掉。

提示：删除本地快照不会影响已经备份到外置硬盘的 Time Machine 完整备份，只是提前释放本机空间。删完之后过几十分钟，系统的「系统数据」统计数字会明显下降，但有时需要重启一次访达或等存储空间界面刷新。

3.2 Docker、虚拟机与模拟器：开发者的隐藏空间黑洞

如果你平时用 Docker、装过虚拟机、或者用 Xcode 跑过 iOS 模拟器，那你的「系统数据」很大一块其实是这些开发工具贡献的。

Docker 的典型症状是~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw这个文件动辄几十 GB。先执行：

docker system prune -a --volumes

这条命令会把所有停止的容器、未被使用的镜像、悬空数据卷全部清理掉。跑完之后如果 Docker.raw 文件还是很大，直接打开 Docker Desktop，进入Troubleshoot，选择Clean / Purge data或者重置磁盘，Docker 会自动把虚拟磁盘文件压缩回收。Docker.raw 文件占的空间主要在镜像和数据卷上，日常使用中那些随手拉下来测试的镜像，用完之后早就忘干净了，攒两三个月就是几十 GB。

iOS 模拟器的情况类似，~/Library/Developer/CoreSimulator/Devices下每一个 Device 都对应一套完整的模拟器系统数据。清理命令分两步，先删除不可用的设备：

xcrun simctl delete unavailable

如果确定所有模拟器都不用了，可以直接：

xcrun simctl delete all

Android 的 AVD 模拟器镜像在~/.android/avd和~/Library/Android/sdk下，不用的系统镜像直接在 Android Studio 的 Device Manager 里删，或者手动删掉~/.android/avd下对应目录。虚拟机软件（Parallels、VMware Fusion、UTM）的虚拟磁盘文件散落在各自的应用支持目录里，一般以.pvm、.vmwarevm、.qcow2结尾，用第二条find命令扫出来的超大文件路径直接能看到，确认没用后整体删除即可。

3.3 缓存、日志与崩溃报告：能清但别乱清

缓存文件在「系统数据」里的占比通常不如快照和虚拟磁盘那么夸张，但积少成多，也能堆出十几二十 GB。重点是挑大个的清理，别把整个缓存目录一锅端。

先看看~/Library/Caches下是谁占了大头：

sudo du -sh ~/Library/Caches/* 2>/dev/null | sort -rh | head -20

输出结果里排在前面的一般是各种浏览器的缓存、微信/钉钉的图片与视频缓存、Adobe 软件缓存、Xcode 的 DerivedData 等。逐项看路径，确认是哪个应用的缓存之后，退出对应应用，再删掉那个目录即可。

日志和崩溃报告的位置主要在两处：/Library/Logs/DiagnosticReports和~/Library/Logs/DiagnosticReports。这两处装的是系统诊断报告和 App 崩溃日志，文件本身不大，但数量极多。用命令直接清空：

sudo rm -rf /Library/Logs/DiagnosticReports/* ~/Library/Logs/DiagnosticReports/*

这些.ips后缀的崩溃报告对普通用户没有任何保留价值，删掉不心疼。

3.4 清理前的红线：这些目录一定不要碰

讲了一堆清理方法，最后必须画几条红线。我见过不止一个朋友把系统文件当缓存删了，结果开机直接进恢复模式，哭都来不及。

第一，/System目录以及/System/Volumes/Data/System目录下的东西不要动。这是系统本身的资源，是只读的，正常情况你也删不掉，但不要因为「权限提示」就去sudo chmod或者sudo rm -rf。

第二，/Library和/System/Volumes/Data/Library下的系统级框架、扩展、启动项，不要轻易删除。这些里面有系统的驱动、字体、配置描述文件，删错了轻则个别功能失效，重则系统无法启动。

第三，任何路径下带vm或者sleepimage字样的文件要谨慎，那是系统的交换文件和睡眠镜像，系统运行期间正在使用，删除了可能导致休眠/唤醒异常。

第四，也是最核心的一条原则：凡是在find结果里看到但无法确认用途的文件，一律先查再删。可以在 Finder 里按路径打开看文件信息，也可以lsof 文件路径看是否有进程正在使用。拿不准就先备份到外置盘再删，或者干脆留着别动。

4. 常见问题与我的排障心得

4.1 清理完系统数据还是没变小？

这是我被问得最多的问题。清理命令都执行了，快照删了，Docker 也 prune 了，怎么系统设置里「系统数据」还是显示几百 GB？

首先，「系统设置 → 存储空间」里的数字不是实时刷新的，它的统计有缓存，可能滞后几十分钟甚至半天。看真实空间占用，请用终端命令：

df -h /

df输出的Avail列才是系统当前真正可用的空间。只要df显示有空间回来了，系统设置里的数字过一会儿自然会跟上。

其次，删除 Time Machine 本地快照之后，APFS 释放空间不一定立刻体现。快照的底层存储是增量式的，系统会在后台合并引用计数，这个回收过程需要时间。如果删完快照一两个小时后空间还是没变，重启一次电脑，基本都会恢复。

最后要考虑是不是 Spotlight 正在重建索引。刚清理完大量缓存和文件之后，Spotlight 会在后台重新扫描文件系统并生成索引，这个过程会临时占用不少空间。别急着继续删，等十几分钟再看。

4.2 两条命令的变体用法与性能优化

很多时候不需要一上来就全盘扫描，可以根据场景灵活调整命令参数。

只想看自己的用户目录，不想看系统级的东西：

sudo du -xhd 1 /System/Volumes/Data/Users/你的用户名 2>/dev/null | sort -rh | head -20

想把扫描范围缩小到「大于 1GB」的文件，进一步减少噪音：

sudo find /System/Volumes/Data -xdev -type f -size +1G -exec ls -lh {} \; 2>/dev/null | sort -k5 -rh | head -30

如果你用的 shell 环境里sort命令不支持-h参数（终端会报invalid option之类的错误），把du命令改成以 KB 为单位排序：

sudo du -xkd 1 /System/Volumes/Data 2>/dev/null | sort -nr | head -20

-k表示以 KB 为输出单位，sort -nr按数字大小倒序排序。虽然 KB 单位看起来不直观，但排序逻辑完全没问题。

4.3 防止「系统数据」再次失控的日常习惯

解决一次 250GB 的问题只是治标，真正重要的是别让它再次失控。我这几年保持下来的一些习惯，直接列给你们作参考。

Time Machine 尽量接外置硬盘。有外置备份盘时，系统倾向于把快照写到备份盘而不会在本机积累太多本地快照。如果实在没有外置盘，建议定期用tmutil listlocalsnapshots /检查一次，发现快照数量变多就手动清一轮。

Docker 用完之后养成docker system prune的习惯。我的一个非常高效的做法是：每次 Docker 虚拟磁盘超过 30GB，就执行 prune，顺便检查有没有镜像已经很久没用了。开发机上保留 1-2 个常用镜像足够，其余随用随拉。

最后，不用 Xcode 的时候把模拟器运行时清理干净，用xcrun simctl delete unavailable把旧版本设备删掉，能省下大量空间。这些习惯每次只花三两分钟，但能帮你把「系统数据」长期压在 50GB 以内。

我个人经验是，macOS 的「系统数据」膨胀，百分之九十都逃不出 Time Machine 快照和开发工具虚拟磁盘这两类。遇到存储告急，先跑一遍两条命令，把账本看清楚，再决定清什么、怎么清。很多时候你以为要重装系统才能解决的大麻烦，其实只需要十分钟命令操作。下一次当你看到「系统数据超过 250GB」时，至少你知道，你不是无能为力。