你的 MacBook 变慢，其实是存储空间的问题吗？

“我的 Mac 变慢了”，人们接下来通常会去看内存占用、活动监视器的 CPU 图表，或者干脆认定这台机器就是老了。而比这些原因都更常见的真正原因，其实很无聊，十秒钟就能查出来：

df -h /

如果 Avail 低于总容量的 10%–15% 左右，那多半就是答案所在——而且和硬件问题不同，这个问题今天下午就能免费解决。

为什么可用空间竟然会影响速度

这一点常常让人意外，因为感觉上两者不该有关系。但有两个机制让这件事真实发生：

虚拟内存需要地方来交换。 macOS 会把可用磁盘空间当作内存的延伸——物理内存用满时，它会把不活跃的数据交换到磁盘上。在一块快满的宗卷上，系统要么没法高效分配交换空间，要么得更费力地去找连续空间，而你感受到的正是大家常描述的那些症状：应用启动变慢、彩虹圈出现得更频繁、负载下整体变得迟钝。

APFS 本身在接近容量上限时效率会下降。 现代 Mac 使用 APFS，一种写时复制（copy-on-write）文件系统，需要有工作空间才能高效完成任务——分配新的文件区段、处理快照、运行后台维护。一块占用 97%–98% 的宗卷，能给 APFS 腾挪的空间，比一块占用 80% 的宗卷明显要少，这种差异会体现为整体系统响应速度，而不只是和存储直接相关的操作。

快速验证的方法

如果你想在花时间清理之前先验证一下这个判断，最快的办法是：按照 “磁盘空间不足”指南里的应急步骤——废纸篓、Downloads、本地 Time Machine 快照、~/Library/Caches——哪怕只腾出 15–20 GB，然后接下来正常使用一小时，看看感觉有没有不一样。如果有，那存储空间才是你真正的瓶颈，而不是大家最先怀疑的 CPU 或内存。

真正不是存储问题的情况

公平地说，也要照顾一下其他解释：如果活动监视器显示某一个具体进程持续把某个 CPU 核心占到 100%，或者你的电池循环次数很高、只在用电池时才变慢，或者只有某个特定应用慢、其他一切都正常——这些指向的是别的问题，再怎么腾出磁盘空间都解决不了。存储空间是最先排查、成本最低的一项，但不是唯一可能的原因。

# 30-second sanity check for a runaway process instead
top -o cpu -n 5

如果某个进程在你没做什么操作的情况下持续占用 90% 以上的 CPU，那就是另一篇文章该解决的问题了——退出或重装那个具体的应用，而不是腾磁盘空间。

开发者会更早感受到这个问题

如果你是开发者，你的磁盘会比普通用户填满得快，原因本博客里都讲过——Xcode 的 DerivedData、Docker 的虚拟机磁盘镜像、散落在你克隆过的每个项目里的 node_modules、IDE 的索引和缓存——这意味着你会比一个只用 Mac 收发邮件、上网浏览的人，更早跨过“存储空间开始拖慢我”的门槛。这也是为什么你真正动手处理时，规模往往更大：开发者的 Mac 上常常堆着 100+ GB 纯粹可再生的构建缓存，处在“有点烦人”和“实实在在拖慢速度”之间。

# The three largest developer-specific hoards, checked in one pass
du -sh ~/Library/Developer/Xcode/DerivedData 2>/dev/null
du -sh ~/Library/Containers/com.docker.docker 2>/dev/null
du -sh ~/Library/Caches/org.swift.swiftpm 2>/dev/null

真正的解决办法，而不是每天的应急招数

腾一次空间只能让你撑几个星期，之后还是会回到这个问题——这个方程里的每一种缓存，都会在你正常使用 Mac 的过程中持续重新填满。眼下可以收藏应急清理指南，每次都手动跑一遍——免费，也确实有效，只是不会自动帮你做。DevCruft 是一款正在开发中、面向开发者的免费 Mac 应用，设计上会把可用空间和究竟是什么在占用它一起显示在地图上，让你不用每次性能下降都凭记忆重新跑五条不同的清理命令。想在它推出时收到通知，可以加入候补名单。