Corespotlightd Issue

July 30, 2025

背景信息

今天再次遇到了corespotlightd进程资源占用高，同时MacBook发热严重的问题。使用sudo mdutil -E /命令重建了索引之后，用mdutil -s /查看索引情况时，经过了几个小时，状态还是一直维持在Indexing enabled（索引已启用），而sudo asitop命令显示性能核心占用长时间处于100%，使用top -o cpu命令查看不同进程占用CPU情况时，经过多小时跟踪，都发现corespotlightd进程资源占用异常。

按照某AI的建议，我使用log stream --predicate 'subsystem == "com.apple.Spotlight" or process == "corespotlightd" or process == "mds"' --style compact这个命令进行诊断（该命令可在终端中输出统一日志系统相关内容），结果发现日志被mds进程的CoreDuet: ClientContext objectForContextualKeyPath:消息刷屏了，根据AI的分析，mds是metadata server（元数据服务）的缩写，是Spotlight的核心后台服务之一，而corespotlightd进程（也就是长时间占用过高CPU能耗的进程）是它的一个辅助进程。而CoreDuet是macOS的一个智能子系统，负责学习用户的使用习惯，以便预测行为、管理电源和调度后台任务。例如，它会告诉Spotlight什么时候是索引的好时机，或者根据用户的上下文（比如打开了哪个应用）来优先索引相关内容。

按照该AI的分析结果，为了彻底解决这个问题，需要重置coreduet的数据库，并再次尝试重建索引，从而让mds进程和coreduet进程能够在一个“干净”的状态下重新开始协作。

解决方案

由于这是一个深层次的修复，需要执行一系列命令，并且涉及到系统底层文件的删除，所以，在停止并禁用spotlight服务之后（这是为了防止spotlight服务干扰这个过程），需要进入恢复模式删除coreduet数据库，并再次删除spotlight索引文件，最后，重新启用并启动spotlight服务，经过一段合理时间的重新索引后，CPU占用率就能恢复正常了。下面是相关步骤：

停止并禁用Spotlight服务

* 这可以防止它在清理文件时捣乱。

* 执行命令（两条命令都要执行）:

sudo launchctl disable system/com.apple.metadata.mds
sudo launchctl stop com.apple.metadata.mds

删除CoreDuet的数据库
- 这是关键一步。这个数据库存储了你的使用习惯和上下文信息。删除它会强制系统重建一个新的、干净的数据库。你的个人数据不会丢失，但系统需要重新学习你的使用模式。
- 执行命令:

sudo rm -rf /private/var/db/CoreDuet/

（再次）删除Spotlight的索引文件
- 既然我们重置了CoreDuet，那么也最好在一个完全干净的索引上开始。
- 执行命令:

sudo mdutil -E /

重新启用并启动Spotlight服务
- 执行命令（两条命令都要执行）:

sudo launchctl enable system/com.apple.metadata.mds
sudo launchctl start com.apple.metadata.mds

如何进入恢复模式

当运行命令删除CoreDuet的数据库时，由于受到系统完整性保护（System Integrity Protection, SIP）的牵制，该文件无法正常删除，虽然可以直接禁用SIP，但是这会降低系统的整体安全性，于是可以进入恢复模式来完成这个操作。在恢复模式下，SIP的部分限制可以被安全地绕过，允许我们执行这种级别的系统维护。下面是进入恢复模式并删除相关文件的方法：

进入恢复模式(Recovery Mode)
```
* 对于搭载苹果芯片（M1/M2/M3/M4, etc）的Mac:

    1. 将你的Mac关机。

    2. 按住电源按钮不放，直到你看到启动选项屏幕（上面会显示你的硬盘图标和“选项”齿轮图标）。

    3. 点击选项(Options)，然后点击“继续”。

* 对于Intel Mac:

    1. 将你的Mac关机。

    2. 按下电源按钮开机，然后立即按住Command (⌘) + R不放。

    3. 直到你看到Apple标志或一个旋转的地球时，松开按键。
```
1. 打开终端
  - 进入恢复模式后，你会看到一个“macOS 恢复”的工具窗口。
  - 在屏幕顶部的菜单栏中，点击实用工具 (Utilities) -> 终端 (Terminal)。
2. 找到你的系统宗卷
  - 在恢复模式的终端中，你的主系统盘路径可能不是 /。我们需要先找到它。
  - 输入命令ls /Volumes/并回车。
  - 在列出的卷中，找到你的主系统盘。通常它的名字是 “Macintosh HD"或你为它取的名字。在后续命令中，我们将以 “Macintosh HD"为例。如果你的盘符名称不同，请替换它。
3. 删除 CoreDuet 数据库
  - 现在，我们要基于上一步找到的宗卷路径来删除那个文件夹。
  - 输入以下命令，并按回车。请注意路径的变化，我们要在宗卷名前面加上/Volumes/。

rm -rf "/Volumes/Macintosh HD/private/var/db/CoreDuet/"

       * 注意1: 如果你的宗卷名包含空格（比如 "Macintosh HD"），必须用引号把它包起来。

       * 注意2: 这个命令在恢复模式下应该会成功执行，不会再提示 Operation not permitted（操作未允许）。

重启电脑
- 删除操作完成后，关闭终端窗口。
- 点击屏幕左上角的苹果菜单，选择重新启动 (Restart)。

编外

正常机器学习训练 VS. 系统故障

之前AI提醒过，CoreDuet是macOS的智能子系统，负责学习用户的使用习惯，以便预测行为、管理电源和调度后台任务。我联想到macOS支持根据电源连接情况判断系统应该直接通过电池供电还是通过电源适配器供电，以尽可能降低电池循环次数，延长电池使用寿命，于是就下意识认为现在这个情况是macOS内置机器学习模型在训练的时候的正常反应。但是询问之后，才知道我遇到的几乎可以确定不是正常的模型训练，而是一个由CoreDuet数据库损坏或状态异常引发的系统服务故障，因为corespotlightd和mds持续数小时占用180%-200%的CPU已经远远超出了正常学习或索引范畴。

另外，日志中CoreDuet消息的刷屏表明的不是一个平静的学习过程，而是一个失控的循环，mds进程可能在疯狂地向CoreDuet请求上下文信息，而 CoreDuet的数据库可能存在某种损坏或不一致的状态，导致每次请求都无法正确完成，从而立即触发下一次请求。这就像一个程序卡在了 while(true)的死循环里，不断消耗资源却没有任何有效产出。

与此相反，正常的机器学习进程应该是较为温和的、断断续续的，例如，这个过程只会在系统闲置时，或者处于锁屏状态时开始，占用的硬件资源也几乎可以忽略不计，而不会长时间占用200%的CPU资源。

删除 CoreDuet 数据库的后果

据介绍，删除这个数据库，确实会重置系统对用户个人使用习惯的学习成果。具体来说，会发生以下情况：

电池健康管理：它会重置学习到的充电模式。如果你之前已经形成了稳定的“优化电池充电”模式（比如每天晚上充电，到早上8点前才充满最后20%），这个模式会消失。系统需要几天到一两周的时间重新学习你的充电习惯，并再次建立这个模式。
Siri 建议：锁屏或搜索时，Siri根据你习惯推荐的应用或快捷指令会暂时消失或变得不那么准。
应用预测：程序坞（Dock）里根据时间或地点建议的应用会失效。
其他智能功能：所有依赖用户行为预测的功能都会回到“出厂设置”。

但是，重要的是，这只是“个性化层”的重置。

核心数据（文件、照片、邮件、应用）毫发无损。
底层的机器学习模型本身（由Apple训练好并内置在系统中的模型）没有被删除。
系统被设计为可以快速地重新学习。在你正常使用电脑几天后，大部分个性化体验就会回来。