先说结论，我最后真正删掉的只有 31G，剩下那 57G 是 macOS 正常该有的东西。但我差点为了这 57G 重装系统，还差点把 Xcode 的 Devices 目录整个端掉，幸好手抖之前多搜了一下。
我这台是 M1 MacBook Air 256G 版本，格式化后系统里显示 245.11 GB。去年十月某天，关于本机 → 更多信息 → 存储空间里那根条，深灰色那截写着「系统数据」88.6 GB，剩余可用掉到 12 GB，Spotlight 开始弹「磁盘几乎已满」，Photos 同步直接卡死。当时我第一反应是中毒了，第二反应是重装。
折腾两个晚上才搞明白一件事：这个数字，macOS 自己在不同版本里都算不明白。Ventura 之前它叫「其他」，之后改叫「系统数据」，本质上就是一个兜底分类 —— 凡是系统不认识的、不属于照片/音乐/邮件/信息/App 的，一股脑塞进这一格。所以它涨得快、删不掉、重启之后数字还会变，全都是正常现象，不是你的机器坏了。
第一步：先搞清楚 Catalina 之后 Mac 的磁盘到底长什么样
如果你上一次认真研究 Mac 磁盘还是 HFS+ 时代，那现在这套东西已经全变了。从 macOS 10.15 Catalina 开始，APFS 卷组里的系统卷是只读的，而且你开机实际运行的那个还不是原始系统卷，是一个快照。
打开终端敲 diskutil apfs list，你会看到一大串卷，但磁盘工具里只显示两个。对你真正有用的是 Data 卷，挂在 /System/Volumes/Data 下面。你的用户目录、缓存、日志、iPhone 备份、Docker 镜像，全在这底下。
所以以后看到「系统数据」很大，第一件事不是打开磁盘工具，是打开终端。Finder 显示的数字和 du 命令算出来的数字对不上，这是常态不是错觉 —— APFS 有 clone、有 purgeable 可清除空间、有快照，三样东西都会让统计失真。磁盘工具里那个「可清除空间」经常显示几十 G，那部分其实是系统觉得「需要的时候随时能还给你」的，不等于真的空着。
第二步：三个真正的元凶，按贡献大小排
本地 Time Machine 快照。 只要你开过时间机器，哪怕外置硬盘现在根本没插着，macOS 也会在本地偷偷拍快照，默认大约每小时一次，保留 24 小时。这是为你服务的东西，不是垃圾文件。查一下：tmutil listlocalsnapshots /。我那台机器上当时躺着 19 个。想全删：sudo tmutil deletelocalsnapshots /。这里有个坑要提醒，网上大量 2015 到 2018 年的老教程会让你敲 sudo tmutil disablelocal，这个命令从 Catalina 起就已经无效了，敲了只会报错，别再跟着试。
Xcode 和模拟器。 如果你装过 Xcode，重点看这几个地方：~/Library/Developer/Xcode/DerivedData（编译中间产物，我见过 40 多 G 的）、~/Library/Developer/Xcode/iOS DeviceSupport（每接一个不同 iOS 版本的设备就存一份符号表，每份 1.5 到 4 GB，我这里有 11 份）、还有 ~/Library/Developer/CoreSimulator/Devices。Xcode 自带的那个清理入口（Xcode → Settings → Locations）其实只清 DerivedData 的一小部分，剩下两个它根本不管。
容器和虚拟机镜像。 ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw，Docker Desktop 默认上限 64 GB，而且你删容器它不会自动缩，这个文件只涨不跌。另外 ~/Library/Application Support/MobileSync/Backup 里的 iPhone 本地备份，一个 256G 的 iPhone 完整备份可以干到 100 GB 以上，很多人根本不知道自己的 Mac 上躺着一份好几年前的手机备份。
第三步：具体怎么查，两条命令就够
第一条，看 Data 卷下一级目录谁最胖：
sudo du -shx /System/Volumes/Data/* 2>/dev/null | sort -hr | head -20加 -x 是关键，不加它会顺着 firmlink 爬到别的卷去，跑一晚上也跑不完。这条命令在我机器上跑了大概 4 分钟，输出里排第一的是 /System/Volumes/Data/Users，第二是 /System/Volumes/Data/private。
第二条，往你自己家里继续往下挖：
sudo du -shx ~/Library/* 2>/dev/null | sort -hr | head -20
然后就顺着最大的那个往下走，一般三到四层就能定位到具体文件。我最后挖出来的是 ~/Library/Application Support/MobileSync/Backup 62 GB 加 Docker.raw 21 GB，这俩加起来 83 GB，占了「系统数据」的绝大部分。
第四步：哪些能删，哪些删了会哭
可以删的：DerivedData 整个目录、iOS DeviceSupport 里你不再调试的旧版本、~/Library/Caches（App 会自己重建，代价只是第一次启动慢一点）、本地快照、Docker.raw（先跑 docker system prune -a 再删文件）、还有你确定不需要的旧 iPhone 备份。
千万别碰的：/System/Volumes/Data/private/var/db 底下的任何东西、/Library/Extensions、以及 /System/Volumes/Data/System。最后这个尤其要注意，它其实是系统卷的可写覆盖层，看着像普通文件夹，删了直接开不了机。另外那种一键清理的付费工具我用了三年，它给我找出来的「垃圾」里好几次包含我自己专门放的重要文件，现在我只信 du 的原始输出。
我自己的看法：别怪大文件，怪 256G 这个配置
清理完之后我的可用空间从 12 GB 回到 43 GB，但三周后「系统数据」又涨到 71 GB。这不是反弹，这就是 Mac 的正常水位。
所以我现在给人推荐 Mac，一律不建议 256G。原因不是你要存很多东西，是 macOS 自己就要吃掉一大块：系统快照 10 到 12 GB、swap（内存不够时拿磁盘顶，8G 内存的机器重度用一天能写进十几 GB）、Spotlight 索引、还有一堆 App 各自的容器缓存。这些加起来在 256G 机器上就是 40 到 60 GB 的固定开销。512G 才是甜点，不是因为你要塞更多文件，是因为你得给系统留出呼吸的余地。
至于「系统数据」这个分类本身，我觉得苹果做得挺鸡贼。它把一堆没法归类的、用户看不懂的东西打包成一个灰色数字，既不解释也不给入口。你说它是 bug 吧，它算得没错；你说它是功能吧，它让你完全没法做决策。我现在的做法是每两个月跑一次上面那两条 du 命令，数字超过 60 GB 就动手挖一挖，平时根本不管它。真要哪天看不顺眼想重装，先老老实实跑完这两条命令再说 —— 我身边三个嚷着要重装 Mac 的朋友，最后都是这么把问题解决掉的。