当 Mac 存储空间紧张的时候，大多数人都会慌张地问同一个问题：空间到底被什么占满了？
这个问题听起来简单，但它跟「怎么删文件」完全是两回事。在动手清理之前，你需要先看清全貌。困难的不是按下删除键，而是找到真正的元凶——而不是被一个笼统的分类标签误导，或者只注意到某个看起来无害的文件夹，又或者只盯上你碰巧发现的第一个大文件。
好的存储诊断应该是结构化的：先看全局概览，再深入目录树，检查最占空间的路径，如果问题反复出现，就对比不同时间点的快照。
要点速览
Storage settings适合快速了解概况，但宽泛的分类标签往往会掩盖真正占空间的路径。Finder适合查看已知文件夹，但无法展示完整的存储树结构，也不能对最重的分支做排名。- 树状视图很关键，因为它把大文件夹放在上下文里展示，而不是让你一个目录一个目录地翻。
- 当前快照回答的是「现在什么最占空间」，对比快照回答的是「什么发生了变化」。
- 最占空间的一般是：下载文件、媒体库、应用支持数据、残留文件、备份、虚拟机、模拟器数据、开发构建产物，以及被归入 System Data 的各种缓存和快照。
- 目标不是找到一个「大文件」，而是搞清楚正确的路径和它的归属，然后再动手清理。
如果大文件是以下几类，这里有专门的排查指南
被归入 System Data 的大文件
深入排查阅读Mac 的 System Data 为什么这么大，了解当系统分类标签只是线索而非诊断结果时该怎么排查。
已卸载应用的残留文件
深入排查查看如何安全清理 Mac 上的应用残留文件，如果大路径来自卸载残留或 Library 支持数据的话。
Apple 开发者相关存储
深入排查参考Xcode DerivedData 占用太多空间？优先清理这些，当大文件夹位于 ~/Library/Developer 下时。
Docker 镜像、层或卷
深入排查阅读Mac 上 Docker 磁盘占用分析：到底是什么在吃空间，当空间被容器而非普通文件夹占满时。
存储问题反复出现
深入排查阅读如何对比 Mac 磁盘使用情况随时间的变化，当真正需要回答的是「两个时间点之间发生了什么变化」时。
为什么 Finder 和存储设置不够用
这两个内置工具各有用处，但都不是完整的解决方案。
Storage settings 擅长告诉你哪个大类看起来可疑。「文稿」占比很高，这有用；「System Data」看起来不对劲，也有用。但分类视图把许多不同的路径压缩到了一个标签下。
问题就在这里——类别告诉你该往哪看，但不告诉你该删什么。
Finder 的短板刚好相反。它是基于路径的工具，不是概览工具。当你已经知道可疑的文件夹时，它很好用；但当真正的问题可能藏在某个意想不到的分支深处时，它就不太行了。
这就是为什么很多人会掉进两种低效的工作方式：
- 过度依赖分类视图，把「System Data」或「文稿」当成一个可以整体清理的目标；
- 在 Finder 里手动翻找，然后假设看到的最大文件夹就是问题的全部。
两种方式都缺少同一样东西：上下文。
macOS 存储设置能告诉你什么
存储设置仍然值得先看一眼，因为它能回答一些宏观问题：
- 压力主要来自个人文件、应用、还是模糊的系统存储；
- 问题像是媒体文件、开发者存储、还是日常文件堆积；
- 哪个类别值得优先深入检查。
作为第一眼概览很有用，但它不能替代真正的路径级检查。
Finder 能告诉你什么
看完概览后，Finder 在检查已知路径、打开可疑文件夹、确认内容是否熟悉方面还是很有用的。
但 Finder 无法自然地回答这些问题：
- 存储树的哪个分支最占空间；
- 哪些大路径分散在完全不同的父文件夹下；
- 某个分类之所以庞大，是因为一个大文件夹还是很多中等大小的文件夹；
- 从上周到今天增长了多少。
而这些往往才是最重要的问题。
为什么存储树能帮你找到 Mac 上占空间的内容
存储树解决了 Finder 和分类视图都留下的可见性问题。
你不需要单独查看一个个孤立的文件夹，而是能看到空间在父路径和子路径之间是如何分配的。这会立刻改变你的诊断思路。
比如：
- 一个庞大的「下载」文件夹，是简单的用户数据清理问题；
~/Library/Application Support下面的大分支，是应用管理的审核问题；~/Library/Developer下面的重度分支，是开发构建产物的问题；- 在某个宽泛的分类下，一个意外占主导的文件夹可能揭示了整个磁盘空间的故事。
这就是为什么树状审查比随机翻找更有用——它同时展示了大小和结构。
为什么 Treemap 能帮你更快找到大文件夹
当你想快速比较同级文件夹时，Treemap 特别好用。不需要逐个打开，你就能看到哪些分支占据了父目录的主要空间。
当你问的是「存储树的哪一部分最值得关注」时，这个视图很有用。
为什么 Sunburst 在路径嵌套很深时有帮助
当你想了解嵌套深度、沿着层级追踪某个重要分支时，Sunburst 视图很实用。
当你问的是「在这个大分支里，空间集中在哪个位置」时，这个视图很有用。
重点不是说哪种可视化效果更好。关键是，当结构信息很重要时，这两种视图都比简单的文件夹列表提供了更多信息。
诊断原则：宽泛的分类告诉你从哪里开始，树状视图告诉你什么才是真正占空间的大户。
当前大小 vs 随时间的增长
这是存储分析中最重要的区分之一。
当前快照回答的是：
- 现在什么最大；
- 哪些文件或文件夹正在占用磁盘；
- 存储树中最重的分支在哪里。
当 Mac 空间满了，你需要判断当前的压力来源时，这是正确的视图。
但有时候更好的问题是另一组：
- 最近什么增长了；
- 自从上次清理之后发生了什么变化；
- 哪个分支每隔几天就在膨胀；
- 某个文件夹是一直很大，还是最近才成为问题。
这是一个关于时间的问题，而不是关于大小的问题。
为什么当前大小和近期增长是不同的问题
一个文件夹可能很大，但几个月都很稳定。这并不意味着它一定是当前存储危机的元凶。
另一个文件夹可能总体不大，但增长速度很快。这也许才是你空间持续减少的真正原因。
所以，单次当前扫描和时间对比不应该被视为可互换的：
Largest告诉你现在什么最重；Reports的快照对比可以告诉你两个时间点之间发生了什么变化。
如果增长问题才是真正的问题，请阅读如何对比 Mac 磁盘使用情况随时间的变化。
很多人忽略了时间维度，结果清理了能看到的大文件，却没解决反复增长的根本原因。
Mac 上一般是哪些东西最占空间
大多数 Mac 的存储空间都被一组可预测的类型消耗。正确的问题不是这些类型是否存在，而是你的机器上目前哪一类最突出。
| 类型 | 为什么会增长 | 首先检查什么 |
|---|---|---|
| 下载、桌面、文稿 | 安装包、导出文件、压缩包、副本、临时项目备份、录音文件悄悄堆积 | 按大小排序，找旧的 DMG、ZIP、视频、重复文件夹和一次性导出 |
| 媒体库 | 照片、视频、屏幕录制、音乐项目和编辑导出天然就很大 | 检查最大的库和已导出的媒体，再处理应用管理的数据 |
| 应用和安装包 | 安装或迁移后，旧的应用包、安装程序和重复的应用副本会残留 | 把已安装的应用和多余的 DMG、存档安装包分开处理 |
| 应用支持数据和残留 | 应用保留缓存、支持文件、容器、日志、索引和本地数据 | 在删除 Library 路径下的任何内容之前，先确认它属于哪个应用 |
| 备份、虚拟机、模拟器数据 | iPhone 备份、虚拟机磁盘和模拟器运行时本身设计就很大 | 确认工作流是否仍在使用，数据是否可以转移而非删除 |
| 开发构建产物 | Xcode、Docker、包缓存、构建输出和运行时为速度优化，而非为空间优化 | 检查这些存储是否是可重建的缓存、保留的运行时状态、还是你还在用的东西 |
| 宽泛的 System Data | 缓存、日志、本地快照、临时文件和各种系统报告混在一起，产生令人困惑的总量 | 在操作之前，找到分类背后真正的大路径 |
下载、桌面和文稿
这些文件夹是最常见的空间大户，因为它们容易被忽视又容易理解。如果其中某个很大，清理起来通常很简单。
照片、视频和导出文件
几个编辑过的视频、屏幕录制、照片库或音频导出可能比几千个普通文件加起来还大。在非开发者的 Mac 上，这些往往是最值得审查的目标。
应用管理的数据
到了这里，大小和风险开始分化。一个路径可能很大，但不一定适合直接删除。如果大分支属于某个应用，先检查那个应用和它的数据模型。如果问题出在已卸载应用的残留，专题指南如何安全清理 Mac 上的应用残留文件是正确的下一步。想了解这个审查步骤在产品中的工作流程，可以直接跳到 App Uninstaller。
备份、虚拟机和模拟器
这些东西本身就很大，所以应该作为完整的工作流来审查，而不是当普通文件夹处理。如果你还在使用它们，更好的做法可能是归档或转移，而不是删除。
开发构建产物
在开发者的 Mac 上，一些最大的路径根本不是个人文件，而是生成的构建输出和运行时存储：Xcode 缓存、模拟器数据、容器层、包缓存和构建产物。如果这确实是问题所在，专门的分类指南比如 Xcode DerivedData 占用太多空间或 Docker 磁盘占用分析比大范围的盲目清理要好。想了解产品中处理这类问题的功能，直接跳到 Dev Cleanup。
当问题看起来像是 System Data 时
如果内置存储概览指向 System Data，这是一个线索，不是诊断。后续指南 Mac 的 System Data 为什么这么大就是专门针对这个问题写的。
查找 Mac 空间占用的实用方法
如果你想要一个可靠的工作流程，按这个顺序来：
1. 从宽泛的分类概览开始
先用内置的存储概览。这里的目标不是精确，而是了解哪个分类值得深入。
2. 查看当前快照中最大的项目
确定了可疑的大分类后，切换到当前快照视图。Largest 比手动翻找更有用，因为它直接展示最重的路径。
3. 在删除任何内容之前打开存储树
确定了重路径后，在树状结构中查看它。Disk Map 把一个大文件变成结构化的解释——它能告诉你问题是单个文件夹、一个子树、还是分散在多个分支上的模式。
4. 清理前先分类
判断路径属于哪个所有权类型：
User-owned：个人文件、导出、下载、归档、媒体；App-owned：支持文件、容器、库、索引、本地数据库；System-owned或工作流拥有：快照、虚拟机、模拟器数据、运行时存储、开发工具。
这个分类通常会直接告诉你下一步应该删除、转移、保留还是继续调查。
5. 如果问题反复出现，对比快照
如果清理之后问题又出现了，别再把它当一次性清理问题来处理了。这是一个增长追踪问题。
这就是 Reports 的价值。对比本地快照可以告诉你两个时间点之间什么增长了、什么缩小了、什么出现了、什么消失了。这比靠记忆回想原因可靠得多。
StorageRadar 在这里能做什么
这在工作流程上带来了实际的改善：
- 从当前快照开始，识别重路径；
- 切换到树状视图，了解上下文；
- 当问题反复出现时，切换到时间对比。
这比靠分类标签猜测或随机翻找文件夹要好得多。
跑一次本地扫描，检查 Largest，然后在删除、归档或转移任何大文件之前打开 Disk Map。
不该做什么
避免这些常见错误：
- 不要把宽泛的分类标签如「System Data」或「文稿」当作安全的清理目标；
- 不要以为在 Finder 里注意到的第一个大文件夹就是问题的全部；
- 不要把「现在很大」和「一直在增长」混为一谈；
- 不要在
~/Library、虚拟机存储、模拟器数据或其他应用或工作流管理的路径里随意操作； - 在搞清楚路径属于谁、删除会有什么后果之前，不要开始删除。
总结
查找 Mac 上什么占空间，本质上不是一个删除问题，而是一个可见性问题。
从全局概览开始，深入目录树，检查当前的重路径，如果问题反复出现就对比不同时间点的快照。一旦你知道了什么是大的、它在哪里、是否在增长，清理的决定就会变得更容易、更安全。
常见问题
怎样找到 Mac 上真正占空间的内容，包括隐藏文件夹？
单靠 Finder 是不够的。Finder 适合查看已知文件夹，但无法展示完整的存储树结构，也不能对不同目录的大小做排名，更没法告诉你空间随时间的变化趋势。
为什么 macOS 的存储设置总是看不够？
存储设置适合做粗略的分类概览，但「文稿」或「System Data」这样的类别底下其实包含了很多完全不同的路径。它能指出方向，但没法精确定位到具体的文件夹或文件。
有什么方法能比逐个翻文件夹更快地找到大文件？
树状视图可以把文件大小放在上下文里展示。不用一个个打开文件夹，你就能看到哪些分支最占空间、父文件夹和子文件夹之间的关系，以及大文件在整个目录结构中的位置。
当前快照和跨时间段的对比有什么区别？
当前快照回答的是「现在什么最占空间」。对比快照回答的是「两个时间点之间什么变大了、变小了、出现了或消失了」。这是两个不同的问题，得出的清理方案通常也不一样。
Mac 上一般是哪些东西最占空间？
常见的空间大户包括：下载文件夹、桌面和文稿里的杂乱文件、照片和视频库、应用的支持数据、已卸载应用的残留文件、备份、虚拟机、模拟器数据、开发工具的构建产物，以及缓存和本地快照等被归入 System Data 的各类数据。
找到大文件后应该马上删掉吗？
不应该。先搞清楚这个路径是你自己创建的、某个应用管理的、还是系统维护的。大文件不一定就能安全删除，尤其是 Library 文件夹、虚拟机存储、模拟器数据或开发工具目录里的文件。