Mac 磁盘已满却看不到大文件？检查 Root 账户的日志文件夹

Q: rtcreportingd 是什么？

一个位于 /usr/libexec/rtcreportingd 的苹果系统守护进程，由 com.apple.rtcreportingd 启动，以 root 身份运行。苹果没有为它提供文档。它的内部结构表明这是一个通过 HTTP 与苹果后端通信、并维护本地缓存的报告服务。它存在于健康的 Mac 上，本身并不是一个问题。

Q: 它是恶意软件吗？

不是。它是位于 /usr/libexec 的一个苹果二进制文件，由密封系统卷内的一个启动守护进程启动。你可以核实它的签名：

Q: root 的 Logs 文件夹占用多少空间才算正常？

在健康的 Mac 上，占用应该很小——这本该是一个你根本不会注意到的文件夹。如果 sudo du -sh /private/var/root/Library/Logs 返回的是两位数以上的 GB，那就是问题所在。苹果没有官方给出的阈值；实际的判断标准是它在 Mac 闲置时会不会继续增长。

Q: 我应该向苹果报告这个问题吗？

如果你遇到了，应该报告。请附上 sudo du -h -d 2 /private/var/root/ 的输出、rtcreportingd 和 fileproviderd 的 CPU 数值，以及是哪个同步客户端停止后解决了问题。苹果目前对此没有发布任何说明，具体的报告正是推动这一点改变的方式。

存储分析工具会漏掉隐藏在 /private/var/root 里的几十 GB 数据。本文教你如何找到失控的 RTCReporting 日志，以及通常导致它们的同步故障。

有一种存储问题，能让大多数人首先想到的工具全部失灵。

Mac 提示磁盘几乎已满。你打开一款存储分析工具，把它找到的内容加起来——总数比 macOS 报告的已用空间少了几十 GB。「磁盘工具」（Disk Utility）显示没有快照。你删除应用、转移照片、清空「废纸篓」，数字却几乎纹丝不动。重启能缓解一小时，然后空间又消失了。

这些文件是真实存在的。你的工具看不到它们，是因为它们藏在 /private/var/root——root 账户的主目录——而你用的每一款工具都是以你自己的用户身份运行的。

在受影响最严重的 Mac 上，罪魁祸首往往只有一个：由名为 rtcreportingd 的系统守护进程写入的日志文件，体积可以达到几十 GB。Michael Tsai 在 2026 年 8 月 21 日记录了一个案例——一台 M4 MacBook Air 上，仅 /private/var/root/Library/Logs 一个目录就占用了 74 GB，清空之后一天之内又涨回了 27 GB。

日志本身不是病因。它们只是一个卡住的守护进程在没人盯着温度计时的外在表现。本文将介绍如何找到被占用的空间、如何在不踩那个会让整个操作前功尽弃的经典误区的前提下回收空间，以及如何找出真正在生成这些日志的进程。

核心要点

/private/var/root 对以你的用户身份运行的任何程序都是不可见的。 我们在 macOS 26.5.2 上确认，执行 ls /private/var/root 会返回 Permission denied。存储分析工具、「访达」（Finder）以及「磁盘工具」的用量数字都会漏掉这里面的内容。
rtcreportingd 是一个真实存在、以 root 身份运行的苹果系统守护进程。 我们核实了它的 launchd 任务声明了 UserName => root，这正是它的日志会落在 root 主目录而不是你自己主目录里的原因。
报告的体积可达几十 GB，而且回涨很快。 记录案例中达到过 74 GB，删除后一天内又涨回 27 GB，因为根本原因仍在持续运行。
一个经典的失误会让整件事白做。 用以 sudo 运行的图形界面工具删除文件时，文件会被移到 root 自己的、你看不到的「废纸篓」里。空间并没有被回收。你必须直接永久删除，或者清空 root 的「废纸篓」。
排查是否有卡死的同步客户端。 在记录案例中，rtcreportingd 和 fileproviderd 都长期占用接近 100% 的 CPU，退出 Dropbox 后两者都停了下来。fileproviderd 是承载云存储 File Provider 扩展的 macOS 进程。
不要在 /private/var/root 里随意删东西。 日志和缓存可以安全删除，但里面其他内容不行，本文会具体说明哪些是哪些。

为什么你的存储工具看不到它

在讲修复方法之前，先说说背后的原理——理解它，才能避免你下次追错方向。

Root 账户有自己的主目录，守护进程也在用它

在 macOS 上，root 账户的主目录是 /private/var/root。大多数人以为它基本上是空的，只有你从 macOS 恢复模式运行「终端」时才会碰到。这个印象已经过时很多年了。以 root 身份运行、需要保存状态、缓存或日志的系统守护进程，会把这些数据写在这里，用的还是和你自己主目录一样的 Library 结构：

/private/var/root/Library/Logs
/private/var/root/Library/Caches

你可以用一条命令确认这个目录对你是禁区。在「终端」没有提升权限的 Mac 上：

ls /private/var/root

我们在 macOS 26.5.2（构建版本 25F84）上原样执行了这条命令，得到：

ls: /private/var/root: Permission denied

这只是普通的 Unix 权限拒绝——root 的主目录被设置为仅限 root 访问。这不是 TCC 隐私保护，也不是「完全磁盘访问权限」能解决的问题。你从「程序坞」启动的存储分析工具是以你的身份运行的，它遍历文件系统时用的也是你的身份，这个目录下的一切对它来说都是地图上的一个空洞。

这就是数字对不上的原因

大家描述的症状是「我的存储工具算出来的总数对不上」，原因就在这里。在记录案例中，OmniDiskSweeper 统计出的文件夹总量，比 macOS 报告的已用空间少了大约 90 GB。

有必要把这个问题和 Mac 可用空间数字对不上的其他原因区分开，因为原因有好几种，而这个漏洞只是其中之一。

Howard Oakley 在 2026 年 8 月 21 日梳理了这套通用的算法逻辑，他自己那台 Mac mini 上的数字很能说明问题：

数据来源	同一卷上报告的已用空间
`diskutil apfs list` 容器差值	837.101 GB
各卷「已用容量」（Capacity Consumed）之和	837.027 GB
「访达」对该卷执行「显示简介」	826.67 GB
「磁盘工具」	814.03 GB

四款工具，四个数字，相差约 23 GB，而一切正常。这些差异来自容器与卷的统计口径不同、可清除空间，以及 APFS 特殊文件的行为：

容器与卷。 一个 APFS 容器里包含多个共享可用空间的卷。「Macintosh HD 上的可用空间」和「容器里的可用空间」是两个不同的问题，答案也不同。
可清除空间。 macOS 会把部分内容标记为「按需可移除」——缓存、部分快照、部分已下载的内容。「磁盘工具」自带的帮助文档写道：「无法手动移除被标记为可清除的文件，但 macOS 会在需要空间时移除它们。」Oakley 测得他的数据卷上有 47.04 GB 的可清除空间。
特殊文件。 APFS 克隆文件在内容分化之前共享存储空间；稀疏文件只存储非空的数据；部分系统文件是压缩过的；无数据文件（dataless files）把数据保存在云端，按需具体化。可用空间的统计依据的是磁盘当前实际存有的内容。

以上这些都不会造成一个持续存在、不断增长、无法解释的 90 GB 缺口。如果你的差距小而稳定，那是正常的统计口径差异。如果差距很大，并且在 Mac 闲置时还在增长，说明有东西在写入你看不到的文件。

对于更常见的存储困惑——「系统数据」（System Data）不会缩小、快照不会释放——我们在 Mac 上系统数据占用巨大和 macOS 存储管理指南里分别讲过。先去看看那两篇。本文讨论的是那些解释都不适用的情况。

rtcreportingd 到底是什么

我们先坦诚说明这里的局限，因为网上很快就会充斥着各种言之凿凿、解释这个苹果从未记录过的守护进程的说法。

我们在 macOS 26.5.2（构建版本 25F84）上直接核实的内容：

可执行文件位于 /usr/libexec/rtcreportingd，大小约 1.45 MB。它的 launchd 任务文件位于 /System/Library/LaunchDaemons/com.apple.rtcreportingd.plist，内容如下：

{
  "EnablePressuredExit" => true
  "EnableTransactions" => true
  "Label" => "com.apple.rtcreportingd"
  "MachServices" => {
    "com.apple.rtcreportingd" => true
  }
  "ProgramArguments" => [
    0 => "/usr/libexec/rtcreportingd"
  ]
  "UserName" => "root"
}

你可以在自己的 Mac 上检查——这个 plist 文件是所有用户都可读的：

plutil -p /System/Library/LaunchDaemons/com.apple.rtcreportingd.plist

UserName => root 就是日志去向的全部解释。 一个以 root 身份运行、写入 ~/Library/Logs 的守护进程，写的其实就是 /private/var/root/Library/Logs。这里没有任何蹊跷之处。

这个二进制文件是用 Swift 写的，用 strings 命令可以看到它内部的类名。其中包括 BackendHTTP、TransparencyLog、StorebagCache、StorebagCoordinator、SessionCoordinator、XPCActivity，还有——请注意这个——CacheCleanupActivity。它的 Mach 服务名包括 com.apple.rtcreporting、com.apple.rtcreporting.pathmonitor 和 com.apple.rtcreportingd.storebag。

我们不会告诉你的是「RTC」到底代表什么，或者这个守护进程具体在报告什么内容。苹果没有记录这些信息，我们也不打算凭空编一个缩写的全称然后当作事实呈现给你。这些类名能支撑起的只是一个保守的描述：这是一个通过 HTTP 与苹果后端通信、在本地缓存状态、监控网络路径可用性、并且有一个定期清理自身缓存的计划任务的报告/遥测服务。

最后这一点才是有意思的地方。这个守护进程本身是有清理逻辑的。 当它的日志涨到几十 GB 时，合理的解读不是「苹果忘了做日志轮转」，而是「有什么东西生成事件的速度超过了守护进程处理和清理的速度」。这就把矛头指向了生成这些事件的源头。

说清楚这个结论的边界：这只是根据类名做出的推断，不是对苹果具体实现的断言。请把它当作一个恰好符合观察到的行为的假设来看待。

「终端」中显示 macOS 磁盘用量分析

找到被占用的空间

接下来的操作都需要 sudo 权限，运行每条命令之前请先读懂它在做什么。

1. 确认差距确实存在

首先看 macOS 认为已经用了多少：

df -h / /System/Volumes/Data

在现代 Mac 上你会看到两行，因为系统卷是一个被密封的只读快照，而你的数据存放在同一容器里的另一个卷上。在我们的测试 Mac 上：

Filesystem        Size    Used   Avail Capacity  Mounted on
/dev/disk3s1s1   926Gi    12Gi   331Gi     4%    /
/dev/disk3s5     926Gi   568Gi   331Gi    64%    /System/Volumes/Data

注意两行报告的 Size 和 Avail 是一样的——这是容器共享的可用空间，而不是每个卷各自的配额。这正是前面提到的「容器与卷」区别的具体体现。

然后检查快照，把这个可能性排除掉：

diskutil apfs listSnapshots /System/Volumes/Data

再看容器视图：

diskutil apfs list

如果快照占用很小，而容器的「已用容量」（Capacity In Use）远高于你的存储分析工具找到的数字，说明你遇到的就是「文件不可见」的问题。

2. 测量 Root 的主目录

找到问题的命令就是这条：

sudo du -h -d 2 /private/var/root/

-d 2 把遍历深度限制在两层，这已经足够看出是 Library/Logs 还是 Library/Caches 是元凶，而不用等待一次完整的遍历。如果机器上确实有个体积很大的目录，这条命令可能要花一两分钟。

想再深入一层、按大小排序查看最大的几个目录：

sudo du -h -d 3 /private/var/root/Library | sort -h | tail -20

在健康的 Mac 上，这些数字都很小——是 MB 级别，不是 GB 级别。如果 /private/var/root/Library/Logs 返回的数字后面跟着「G」，前面还不止一位数字，那就是你丢失的那部分空间。

3. 查看里面到底有什么

删除任何东西之前，先看一眼：

sudo ls -la /private/var/root/Library/Logs
sudo du -h -d 1 /private/var/root/Library/Logs | sort -h | tail

在记录案例中，里面的内容「几乎全部来自 RTCReporting」。如果你这里主要是别的东西，那接下来该做什么就会不一样——本文的诊断思路依然适用，只是元凶会是另一个子系统。

4. 图形界面替代方案

如果你更想在窗口里看到这一切，OmniDiskSweeper 是免费的，也正是最初那篇报告里发现问题所用的工具。关键在于：你必须以提升过的权限重新启动它，它才能看到 root 的主目录。正常方式启动的话，它给你看到的画面和其他工具一样是不完整的。

我们的存储分析工具汇总介绍了各种选择，但请注意同样的限制对它们全部适用：只要工具不是以 root 身份运行，这部分空间对它来说就是不可见的。

回收空间——以及那个会让整件事白做的失误

这里有个陷阱，而且是个相当高明的陷阱。

如果你用一个以 sudo 运行的图形界面工具删除这些文件，工具会做它一贯会做的事：把文件移到「废纸篓」。但因为这个进程是以 root 身份运行的，那其实是root 自己的「废纸篓」，位于 /private/var/root/.Trash，它不会出现在你的「程序坞」里，你也永远不会想到要去清空它。文件其实还在磁盘上。你的可用空间没有变化。你会以为删除没有生效。

具体到 OmniDiskSweeper，按住 Option 键可以把「Delete」变成「Delete Immediately」（立即删除）。

从「终端」直接删除日志内容：

sudo rm -rf /private/var/root/Library/Logs/*

运行这条命令之前请先读懂它。它删除的是 root 的 Logs 目录里面的内容，仅此而已。不要缩短这个路径，也不要在斜杠前面加空格。

然后检查一下 root 的「废纸篓」里是不是还留着之前尝试删除时产生的文件：

sudo du -sh /private/var/root/.Trash

如果有的话：

sudo rm -rf /private/var/root/.Trash/*

root 主目录里的缓存通常也可以安全清除——从定义上讲，缓存本来就是可以重新生成的：

sudo du -h -d 1 /private/var/root/Library/Caches | sort -h | tail

不要碰的东西。 不要删除 /private/var/root 本身。不要整体删除 /private/var/root/Library。不要去删除钥匙串、偏好设置或任何你认不出来的东西。日志和缓存是安全的类别；里面其他的一切都属于某个系统组件，它们出现在那里是有原因的。

之后重启一下。然后用 df -h 再检查一次，确认空间确实回来了。

接下来，找出真正的原因

如果你只做到删除这一步，空间会先回来，然后再次消失。在记录案例中，重启后几分钟内就又涨回了 5 GB，一天之内涨到 27 GB。

观察 CPU 占用

打开「活动监视器」（Activity Monitor），按 % CPU 排序，留意两个进程：

rtcreportingd —— 写入日志的守护进程
fileproviderd —— 承载云存储 File Provider 扩展的 macOS 进程

在记录案例中，两者在一台闲置的 Mac 上持续占用接近 100% 的 CPU。

从「终端」查看：

ps -Ao pid,pcpu,comm | grep -E 'rtcreportingd|fileproviderd'

这两个进程在任何健康的 Mac 上都存在并且会运行——我们在自己那台完全没有存储问题的测试机上也确认了两者都在运行。它们存在是正常的，持续占用 CPU 才不正常。 同步进行中占用百分之几是可以预期的；Mac 没人碰却停在 90%-100%，才是问题的信号。

观察日志增长

最直接的确认方法是测量两次：

sudo du -sh /private/var/root/Library/Logs

让 Mac 闲置十分钟，然后再运行一次。在健康的 Mac 上，这个数字不会有明显变化。如果你什么都没做，数字却明显在涨，说明有什么东西陷入了循环。

首先怀疑云同步

fileproviderd 是最明显的线索。它是承载 File Provider 扩展的系统进程——这是 Dropbox、OneDrive、Google Drive、Box 和 iCloud Drive 都在用的现代机制，用来在「访达」里呈现云端文件。如果它在持续消耗 CPU，说明其中某个扩展卡住了。

在记录案例中，出问题的客户端是 Dropbox，在那台 Mac 上它已经异常运行了大约一年——没有按配置保留文件的离线副本，而且看起来即使什么都没变也在持续同步。退出 Dropbox 后，CPU 占用和日志增长立刻都停止了。

想在自己的 Mac 上测试这一点，可以逐个退出同步客户端并观察。要彻底退出客户端——点菜单栏图标，选择「退出」——而不是只暂停同步，因为暂停状态下扩展可能仍然处于加载状态。

# after quitting a sync client, check whether the load dropped
ps -Ao pid,pcpu,comm | grep -E 'rtcreportingd|fileproviderd'

如果退出某一个客户端后两个进程都回落到空闲状态，你就找到元凶了。

如何处理这个同步客户端

以下方案大致按所需精力从小到大排列：

更新它。 File Provider 扩展的漏洞很常见，也经常会被修复。先检查有没有更新可用。
退出登录再重新登录。 这会重建扩展的本地状态，能解决相当多卡住的同步问题，效果出乎意料地好。
卸载再重新安装客户端。 更折腾，但更彻底。
把数据迁移到别处。 在记录案例中，最终的解决方案是迁移到 iCloud Drive——因为 Dropbox 无法可靠地下载文件完成迁移，作者最后改用 Dropbox 的网页版界面下载了整个文件夹。之后 iCloud Drive「很快就上传完了所有内容，然后就安静下来，不再占用 CPU 了」。

最后这一点值得坦诚提醒一下：在源客户端已经故障的情况下在云服务商之间迁移数据，确实很痛苦，网页版界面可能是你最可靠的导出途径。我们的 iCloud Drive 完整指南介绍了迁移目的地那一端的内容；如果 iCloud Drive 本身也出问题，iCloud Drive 自动下载漏洞是另一个已知的独立问题。

我们并不是说只有 Dropbox 会出这种问题。它只是记录案例中涉及的客户端。任何 File Provider 扩展都可能卡住，无论你用的是哪一个，诊断方法都是一样的。

「活动监视器」中显示高 CPU 占用的进程

其他会对你隐藏存储占用的地方

root 的主目录是几乎没人会去检查的地方，但它不是唯一一个用户级工具会失手的地方。如果你的差距不在 /private/var/root 里，在断定数字有问题之前，先把下面这些都排查一遍。

其他守护进程归 root 所有的数据。 /private/var/root 是 root 主目录所在的位置，但系统组件也会往 /private/var/db、/private/var/folders 和 /Library/Logs 下面写数据。用同样的方法测量它们：

sudo du -h -d 1 /private/var/db | sort -h | tail
sudo du -h -d 1 /Library/Logs | sort -h | tail
sudo du -sh /private/var/folders

/private/var/folders 存放的是各用户的临时和缓存容器，正常情况下就可能达到几个 GB。它由 macOS 自行管理，一般应该保持原样不去动它；重启会清除其中易失的部分。

本地时间机器（Time Machine）快照。 这是最常被怀疑、但实际上很少是真凶的原因。别靠猜测，直接检查：

tmutil listlocalsnapshots /
diskutil apfs listSnapshots /System/Volumes/Data

如果快照确实是问题所在，macOS 会在空间紧张时自动精简它们，更深入的情况我们在时间机器故障排查指南里有介绍。

其他用户的主目录。 说破了很明显，实际却很容易被忽略——Mac 上另一个账户里存了 200 GB 的视频，你的存储工具以你的身份运行时是不会显示给你看的。一条 sudo du -h -d 1 /Users 就能给出答案。

被正在运行的进程占用打开的文件。 已经删除但空间没有释放，因为某个进程还持有那个文件描述符。这种情况的特征是重启之后差距就消失了：

sudo lsof / 2>/dev/null | grep -i deleted | head

「邮件」本地存储、iOS 设备备份和 Xcode。 这是开发者或重度使用「邮件」的用户 Mac 上三个经典的「体积大又容易被忘记」的目录：

du -sh ~/Library/Mail
du -sh ~/Library/Application\ Support/MobileSync/Backup
du -sh ~/Library/Developer/Xcode/{DerivedData,iOS\ DeviceSupport,Archives} 2>/dev/null

这几个目录以你自己的用户身份就能读取，所以存储分析工具确实能找到它们——只是它们会淹没在一长串列表里。在提权用 sudo 之前，值得先检查一下这几个。

云端占位文件被具体化。 如果你在任何同步客户端里使用了「仅保留在线」这类设置，一个漏洞或者一次全文搜索都可能悄悄把所有内容下载下来。这属于和本文相同的一类故障，通常表现为同步文件夹本身在持续增长。

这个问题有多普遍？

老实说：我们不知道，写这个话题的其他人也不知道。

目前公开记录里有：一篇带具体数字和具体解决方案的第一手记录、一个关于 RTCReporting 存储占用的 Apple 支持社区帖子，以及一个 Reddit 帖子，里面用户在问是什么占用了他们的存储空间。这些足以证明这个问题是真实存在且可复现的，但不足以说明有多大比例的 Mac 受到影响。

根据我们自己的核查，可以说的是：rtcreportingd 在一台没有存储问题的常规 Mac 上也在运行，那里的日志毫不起眼，而且这个守护进程确实有清理逻辑，大多数时候也确实在起作用。这是一种故障模式，不是默认行为。如果你 Mac 的存储数字能对得上，就没什么需要修复的。

苹果没有就此发布任何支持文档，没有承认这个问题，也没有推出有记录的修复方案。如果你遇到了，花五分钟给苹果提交反馈是值得的——一个没被承认的问题，会一直不被承认下去。

常见问题排查

`sudo du` 运行个没完

在一个庞大或者高度碎片化的目录树上，这是正常现象。先用 -d 1 找出哪个顶层文件夹比较大，然后只深入那一个。如果你已经知道自己关心哪个目录，就不要对整个磁盘运行 du。

我删除了日志，但可用空间没有变化

这是「废纸篓」的问题。检查 sudo du -sh /private/var/root/.Trash，然后用 sudo rm -rf /private/var/root/.Trash/* 清空它。几乎所有用图形界面工具删除的人都会踩到这一点。

第二种可能是某个进程仍然打开着已删除的文件，这种情况下要等该进程退出，空间才会被释放。重启 Mac 后再检查一次。

空间在一天之内又涨回来了

如果你还没找到根本原因，这是预料之中的。删除日志只是处理了症状。去做「活动监视器」那一步，找出到底是什么在循环。

`rtcreportingd` 在占用 CPU，但我没装任何云同步客户端

那触发因素就是别的东西了。在「活动监视器」里按 CPU 排序，看看还有什么在忙碌。检查统一日志（unified log），查看这个守护进程自身的活动：

log show --predicate 'process == "rtcreportingd"' --last 1h --info | head -50

请注意，统一日志查询只会返回实际写入过的内容，而且日志数据会过期——查询一个很长的时间窗口，完全有可能什么都查不到。

「磁盘工具」的「急救」显示磁盘没问题

它当然会这么说。这不是文件系统损坏。「急救」（First Aid）检查的是元数据一致性；一个装满了大而有效的文件的目录，一致性完全没问题。

我能直接禁用 rtcreportingd 吗？

我们不建议这么做。它是一个苹果系统守护进程，运行在启用了「系统完整性保护」（System Integrity Protection）的 Mac 上；为了绕开一个症状而禁用系统启动守护进程，往往会在之后制造出第二个、更不明显的问题。应该去修复驱动它的那个进程。如果这个守护进程在没有可辨认触发因素的情况下就出现异常，那是一个值得报告给苹果的漏洞，而不是应该绕过去的东西。

我的 Mac 空间不够了，现在马上就需要腾出空间

在你诊断问题的同时，可以立刻做这些安全的操作：清空你自己的「废纸篓」、按上面的方法清空 root 的「废纸篓」、删除 root 的 Logs 内容，再检查一下 sudo du -h -d 1 /private/var/root/Library/Caches。这几步加起来通常能腾出足够的空间，让 Mac 在你排查根本原因的同时恢复可用。如果这个问题恰好卡住了 macOS 更新，我们的空间不足导致更新失败指南专门讲了该怎么办。

FAQ

`/private/var/root` 是什么？

它是 macOS 上 root 账户的主目录。只有 root 才能读取它，这也是为什么以你的用户身份运行的工具看不到里面的内容。以 root 身份运行的系统守护进程会把日志、缓存和状态数据存放在这里，用的是和你自己主目录一样的 Library 结构。

为什么「访达」或我的存储应用看不到这些文件？

因为它们以你的身份运行，而这个目录的 Unix 权限把你的用户排除在外。这不是「完全磁盘访问权限」能解除的隐私保护——它就是普通的文件权限。图形界面工具必须以提升过的权限重新启动，才能遍历这个目录。

`rtcreportingd` 是什么？

一个位于 /usr/libexec/rtcreportingd 的苹果系统守护进程，由 com.apple.rtcreportingd 启动，以 root 身份运行。苹果没有为它提供文档。它的内部结构表明这是一个通过 HTTP 与苹果后端通信、并维护本地缓存的报告服务。它存在于健康的 Mac 上，本身并不是一个问题。

它是恶意软件吗？

不是。它是位于 /usr/libexec 的一个苹果二进制文件，由密封系统卷内的一个启动守护进程启动。你可以核实它的签名：

codesign -dv --verbose=2 /usr/libexec/rtcreportingd

root 的 Logs 文件夹占用多少空间才算正常？

在健康的 Mac 上，占用应该很小——这本该是一个你根本不会注意到的文件夹。如果 sudo du -sh /private/var/root/Library/Logs 返回的是两位数以上的 GB，那就是问题所在。苹果没有官方给出的阈值；实际的判断标准是它在 Mac 闲置时会不会继续增长。

Mac 清理类应用能解决这个问题吗？

几乎肯定不能，原因和你的存储分析工具漏掉它一样：除非这个清理工具提升权限、并且专门遍历 root 的主目录，否则它根本看不到这些文件。而且就算某个清理工具删除了它们，也阻止不了文件再涨回来，因为根本原因是一个陷入循环的进程，而不是堆积的垃圾文件。

这个问题只影响特定的 Mac 或特定的 macOS 版本吗？

目前公开的数据还不足以下结论。记录案例发生在一台 M4 MacBook Air 上。我们是在 macOS 26.5.2 上核实这个守护进程和权限行为的。这个机制没有任何一点是特定于某款芯片或某个 macOS 版本的——root 拥有主目录这件事，从 macOS 诞生之初就一直如此。

我应该向苹果报告这个问题吗？

如果你遇到了，应该报告。请附上 sudo du -h -d 2 /private/var/root/ 的输出、rtcreportingd 和 fileproviderd 的 CPU 数值，以及是哪个同步客户端停止后解决了问题。苹果目前对此没有发布任何说明，具体的报告正是推动这一点改变的方式。

结语

这个问题之所以让人抓狂，是因为你对 Mac 存储的每一个直觉在它面前都是错的。这些文件不在你能找到的文件夹里，不是快照，也不是「存储」面板意义上的「系统数据」。删应用没用，数字对不上，而唯一能让你看到真相的那个工具，恰恰是你从没想过要用 sudo 运行的那个。

一旦知道该去哪里找，这就是个十分钟就能搞定的活儿：用 du 测量 /private/var/root、删除日志、清空 root 的「废纸篓」，然后——真正重要的一步——盯着「活动监视器」，直到找出是哪个进程在把空间重新填满。十次里有九次，只要看到 fileproviderd 和 rtcreportingd 一起出现在 CPU 列表里，那就是一个已经悄悄坏掉好几个月的云同步客户端。

而如果你 Mac 的存储数字只是相差几个 GB，而不是九十 GB，那就放心好了。这只是 APFS 一贯的行事方式，Howard Oakley 的那套算法已经把它完全解释清楚了。

信息来源： Michael Tsai，《Huge RTCReporting Logs and Dropbox》，2026 年 8 月 21 日 · The Eclectic Light Company，《The arithmetic of free space》，2026 年 8 月 21 日 · Apple 支持社区帖子 254838127（RTCReporting）· 苹果《磁盘工具》帮助文档（可清除空间）· 2026 年 8 月 22 日在 macOS 26.5.2（构建版本 25F84）上使用 ls、plutil、strings、df 和 ps 进行的本地核实。