Mac 磁盘满了怎么办？按这 5 步操作，我清理出了 50GB 空间

摘要：Mac 弹出"磁盘空间不足"是无数用户的噩梦——"系统数据"动辄近百 GB，灰色不可点击，无从下手。本文提供一套实测 5 步清理法：用 SpacePeek 快速诊断空间杀手→精准定位 Docker/Xcode/缓存等五大元凶→每条命令附带安全性说明→最终清理出 52GB。全文标注风险等级，可作为 Mac 定期清理参考手册。

本文信息：基于 macOS 15.0 Sequoia 实测编写，所有清理命令均经过验证。本文提供的是方法论 + 诊断工具 + 安全清理路径，不是一键删除脚本——每一步都有安全性说明，请放心操作。

---

一、问题背景

永远在"爆满"边缘的 Mac 硬盘

上个月某天下午，我正在写代码，屏幕右上角弹出了一个我再熟悉不过的通知：

“磁盘空间不足”

打开「系统设置 → 通用 → 存储」，一个彩色的容量条红到了极限。总共 256GB 的硬盘，"系统数据"一栏占了 98GB——灰色的，不可点击，没有明细。

那一刻我的心理活动三步走：

1. 否认：不可能，我没什么大文件
2. 愤怒：98GB 的"系统数据"到底是什么东西？
3. 接受：行吧，又一次大扫除

但这一次，我决定不再凭感觉"猜"哪些文件夹大——而是用一个系统化的流程，从诊断到清理，每一步都有工具支撑。最终结果：清理出 52.3GB，系统数据从 98GB 降到 43GB。

这篇文章就是这个流程的完整记录。

阅读收益

读完你会得到：

• 一套可复现的"Mac 磁盘清理 5 步法"
• 每一步用到的工具和命令（附安全性说明）
• 最常见的 5 个"隐形空间杀手"的清理方式
• 一个选择题：清理完之后，怎么防止再次爆满

---

二、五步清理法总览

第 1 步：诊断   → 用 SpacePeek 找到哪些文件夹在吃空间
第 2 步：深挖   → 逐层下钻找到根因（Pro 功能 or 手动）
第 3 步：清理   → 针对不同"元凶"的安全删除方法
第 4 步：缓存   → 清理系统缓存和可重建数据
第 5 步：预防   → 设置日常监控，不再突击清理

---

三、每一步详解

---

第 1 步：诊断 —— 找到最大的文件夹

目标：不靠猜，不靠逐个右键→显示简介，在 5 分钟内完成全盘主要文件夹的大小统计。

工具：SpacePeek（免费，App Store 下载）

为什么用 SpacePeek 而不是 DaisyDisk：

DaisyDisk 做全盘扫描需要 2-5 分钟，而且会生成一个太阳图让你理解全局。但问题是——全盘扫描完之后，你需要从太阳图里找一个色块，再去 Finder 里找到对应的文件夹路径，再手动清理。步骤太多。

SpacePeek 的优势在于它嵌入 Finder 的工作流：你在 Finder 里浏览文件 → 看到可疑文件夹 → 随手按空格 → 知道它多大 → 继续浏览。这是一个"边逛边查"的模式，比"先全局扫描再逐个处理"效率高。

操作流程：

1. 打开 Finder，按 ⇧⌘H 进入个人目录（~/）
2. 看到 Library、Documents、Downloads、Desktop……
3. 对着每个文件夹按空格

我的实测数据：

文件夹	大小	疑似元凶
~/Library	127 GB	⚠️ 最大嫌疑
~/Downloads	23 GB	半年没清理
~/Documents	15 GB	正常
~/Desktop	2 GB	正常
~/Movies	8 GB	一些录屏素材
~/Music	0.5 GB	正常

命中目标：~/Library 占了 127GB，占整盘的一半。接下来第 2 步，对它下手。

为什么 Library 这么大是正常的：~/Library 是 macOS 的"数据仓库"——应用缓存、Xcode 构建产物、Docker 镜像、浏览器缓存、邮件附件、Time Machine 本地快照……全在里面。它不是"垃圾"，但有很多是可以安全清理的。

---

第 2 步：深挖 —— 逐层下钻找到根因

目标：面对 127GB 的 ~/Library，不能盲目删除。需要精准定位哪些子文件夹是膨胀的源头。

工具：SpacePeek（免费版的饼图已经够用，Pro 版可以逐层双击下钻）

操作流程：

选中 ~/Library → 按空格 → SpacePeek 弹出预览面板，饼图显示子文件夹占比。

我的实测结果：

子文件夹	大小	占比	对应元凶
Containers	45 GB	35%	Docker 镜像 + 应用容器
Developer	32 GB	25%	Xcode DerivedData + 旧 iOS 固件
Application Support	18 GB	14%	各应用的数据文件
Caches	14 GB	11%	系统和应用缓存
Group Containers	8 GB	6%	应用组共享数据
其他	10 GB	8%	—

三大元凶锁定：Docker、Xcode、Caches。

继续下钻（用 SpacePeek Pro 的无限下钻功能，或者手动进入 Finder 逐层查看）：

进入 Containers → 按空格 → 饼图里 com.docker.docker 占了 38GB。这就是 Docker 的虚拟机磁盘镜像。

进入 Developer → 饼图里 Xcode/DerivedData 12GB、Xcode/iOS DeviceSupport 14GB、CoreSimulator 6GB。

如果你没有 Pro：手动进入 Finder，路径是 ~/Library/Containers/com.docker.docker/ 和 ~/Library/Developer/Xcode/，一样可以看到——只是多几次点击。

---

第 3 步：清理 —— 五大元凶的安全删除方法

确定了根因之后，接下来是逐一清理。以下是针对最常见的 5 个空间杀手的安全清理方法：

---

元凶 1：Docker 磁盘镜像（38 GB）

根因：Docker Desktop for Mac 使用虚拟机运行容器，虚拟机磁盘镜像（Docker.raw）只增不减。即使你删除了所有容器和镜像，这个文件也不会自动缩小。

清理命令：

# 清理所有停止的容器、未使用的镜像、构建缓存
docker system prune -a --volumes

预期释放：15-25 GB（取决于你的 Docker 使用历史）

安全性：✅ 安全。该命令只删除未被任何运行中容器使用的资源。如果你有需要保留的镜像，先 docker images 确认。

如果上述命令释放不够多（镜像文件本身已膨胀）：

# 更彻底的方案：重置 Docker 到出厂状态
# ⚠️ 这会删除所有容器、镜像、卷，相当于重装 Docker
# 使用前请确保不需要的数据已备份

在 Docker Desktop → Troubleshoot → Reset to factory defaults。

---

元凶 2：Xcode 构建产物和旧固件（32 GB）

根因：Xcode 的 DerivedData（编译中间产物）、iOS DeviceSupport（旧 iOS 版本调试符号）、Archives（App Store 提交包）不会自动清理。

清理命令：

# 1. 清理 DerivedData（安全，下次编译会自动重建）
rm -rf ~/Library/Developer/Xcode/DerivedData/*

# 2. 清理旧的 iOS DeviceSupport（安全，连接设备时会重新下载）
# 先看看有哪些版本
ls ~/Library/Developer/Xcode/iOS\ DeviceSupport/
# 保留当前需要的版本，删除旧版
rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/15.0
rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/16.0

# 3. 清理不可用的模拟器数据
xcrun simctl delete unavailable

预期释放：15-25 GB

安全性：

• ✅ DerivedData：完全安全，下一次编译会重建。唯一的"代价"是第一次编译慢一些。
• ✅ iOS DeviceSupport：安全，连接设备时会自动重新获取符号。
• ✅ simctl delete unavailable：安全，只删除当前系统不支持的旧模拟器。
  

---

元凶 3：系统与应用缓存（14 GB）

根因：macOS 和应用程序会缓存各种数据加速访问——浏览器缓存、系统日志、字体缓存、Quick Look 缓存等。这些可以安全删除，系统会在需要时重建。

清理命令：

# 1. 清理用户缓存（安全）
rm -rf ~/Library/Caches/*

# 2. 清理系统日志（安全）
sudo rm -rf /private/var/log/*

# 3. 清理 Quick Look 缓存（安全）
qlmanage -r cache

# 4. 重启 Finder 使更改生效
killall Finder

预期释放：5-10 GB

安全性：✅ 全部安全。缓存文件和日志是系统的"临时加速数据"，删除后系统会自动重建。

---

元凶 4：Downloads 文件夹中的陈年文件（23 GB）

根因：下载的 DMG 安装包、PDF 文档、ZIP 压缩包……下载完就忘了，堆积成山。

诊断方法：用 SpacePeek 选中 Downloads 文件夹 → 按空格 → 查看「文件年龄分析」。

我的数据：最近 7 天 2.1GB / 30 天 4.5GB / 半年 8.2GB / 一年以上 8.4GB。

清理方法：

# 在 Finder 中打开 Downloads
# 按"添加日期"列排序
# 删除半年前的文件（基本都是安装包）

不需要命令——直接在 Finder 里按修改日期排序，批量选中拖入废纸篓即可。

预期释放：5-15 GB

安全性：⚠️ 半安全。删除前快速浏览一遍，确认没有重要的下载文件（如合同、证件扫描件等）。

---

元凶 5：Time Machine 本地快照

根因：macOS 会在本地磁盘上保存 Time Machine 的本地快照（即使你没有外接备份硬盘）。系统设置里显示为"系统数据"或"可清除"，但有时不会自动释放。

诊断命令：

# 查看本地快照
tmutil listlocalsnapshots /

清理命令：

# 删除所有本地快照（不影响外接硬盘上的 Time Machine 备份）
sudo tmutil deletelocalsnapshots /

预期释放：10-30 GB（取决于上次备份时间）

安全性：✅ 安全。只删除本地存储的快照副本，不影响外接硬盘上的正式 Time Machine 备份。下次连接备份硬盘时会重新创建本地快照。

---

📊 清理结果汇总

元凶	清理前	释放量	清理后	方法
Docker 镜像	38 GB	25 GB	13 GB	docker system prune -a
Xcode 构建产物	12 GB	12 GB	0 GB	rm -rf DerivedData/*
iOS DeviceSupport	14 GB	10 GB	4 GB	删除旧版本
系统缓存	14 GB	8 GB	6 GB	rm -rf ~/Library/Caches/*
Downloads	23 GB	8 GB	15 GB	手动删除
Time Machine 快照	(含在系统数据中)	15 GB	—	tmutil deletelocalsnapshots
合计	—	~52 GB	—	—

系统数据从 98GB → 43GB，磁盘可用空间从 2.3GB → 54.3GB。

---

第 4 步：缓存清理 —— 扫尾工作

前三步已经处理了主要的空间杀手。这一步处理一些零散的、但加起来也不少的"隐形占用"。

# 清理 Homebrew 缓存（下载过的安装包）
brew cleanup --prune=all

# 清理 npm 缓存（如果你做前端开发）
npm cache clean --force

# 清理 Yarn 缓存
yarn cache clean

# 清理 Gradle 缓存（如果你做 Android 开发）
rm -rf ~/.gradle/caches/

# 清理 VS Code 的 Crash Report 缓存
rm -rf ~/Library/Application\ Support/Code/Crashpad/completed/*

预期释放：2-5 GB

---

第 5 步：预防 —— 设置日常监控，不再突击清理

清理完之后的真正挑战是：不要再回到每季度突击清理的模式。

日常监控方案：

层级	工具	做什么	频率
菜单栏	Stats（免费）	磁盘模块显示剩余空间，变黄时立刻知道	始终运行
浏览时	SpacePeek	日常浏览文件夹时随手按空格，养成"空间感知"习惯	自然使用
周期性	每月 1 号	打开 Downloads → 删除 30 天前的文件	每月 1 次
按需	Docker	docker system df 查看镜像占用，大了就 prune	每月 1 次

一个小技巧：在 Stats 的磁盘模块中把预警阈值设为 20GB。当菜单栏图标变黄，你就知道该"顺手打扫"了——而不是等到系统弹窗才行动。

---

四、安全警告（必读）

操作	风险等级	说明
rm -rf ~/Library/Caches/*	🟢 安全	系统会自动重建缓存
rm -rf ~/Library/Developer/Xcode/DerivedData/*	🟢 安全	下次编译自动重建
docker system prune -a	🟢 安全	只删除未使用的镜像/容器
sudo tmutil deletelocalsnapshots /	🟢 安全	不影响外接备份
手动删除 Downloads 文件	🟡 需确认	删除前看一眼内容
rm -rf ~/Library/Developer/Xcode/iOS DeviceSupport/*	🟡 需确认	只删旧版本，保留当前使用的
rm -rf ~/Library/Application Support/	🔴 危险	绝对不要执行——会删除应用数据

⚠️ 最后一条不是玩笑：Application Support 里存的是应用的配置和数据（如 Chrome 的书签、VS Code 的插件配置等）。你在 SpacePeek 中看到它占了 18GB 是正常的——不要删它。如果你需要对某个具体应用的臃肿数据做清理，针对那个应用单独处理。

---

五、总结

五个关键认知

1. "系统数据"大不是 bug，是需要你手动清理的正常现象。 macOS 的缓存策略偏向"尽可能多用空间来提速"，它假设你会在空间不足时手动介入。SpacePeek 让你能精准介入，而不是盲目地到处找。

2. Docker 和 Xcode 是开发者 Mac 的两大空间杀手。 这两个工具的缓存和镜像管理几乎不会自动清理。养成每月 docker system prune -a 和清理 DerivedData 的习惯，你的 Mac 会多出 30-50GB。

3. SpacePeek 改变了清理的工作流。 以前是"先全盘扫描 → 再定位 → 再手动找路径 → 再清理"。现在是"浏览文件夹 → 随手按空格 → 知道大小 → 决定是否清理"。这个工作流的变化让清理从"大扫除"变成了"日常随手整理"。

4. 清理之后，预防比突击更重要。 Stats 菜单栏监控 + SpacePeek 日常感知 = 不再需要每季度大扫除。

5. 安全第一。 所有本文给出的命令都经过验证和标注风险等级。如果你对某个命令不确定，先 Google 一下那个路径是干什么的——宁愿多花 2 分钟确认，不要盲删。

版本信息

项目	信息
测试环境	macOS 15.0 Sequoia, MacBook Pro M3 Pro, 256GB
诊断工具	SpacePeek v1.1（免费版）
监控工具	Stats（免费开源）
日期	2026 年 7 月

---

你的 Mac 上发现过最大的"隐形空间杀手"是什么文件？评论区晒出来——看看谁的最离谱。