corespotlightd 占用 CPU 很高，先查是哪款应用触发
活动监视器里 corespotlightd 一直排在前面，先看它是不是跟某个 App 的打开、更新或导入一起出现，高 CPU 只能说明它正在忙，不能据此认定启动磁盘的 Spotlight 索引坏了，直接删数据库还可能丢掉排查线索，让索引从头再跑。
App 内容搜索和文件搜索要分开看
Core Spotlight 让 App 把自己的内容交给系统搜索，文档 App 提交的搜索条目，不一定对应访达里的一份普通文件，Apple 的内容索引指南也说明了 App 怎样随着内容变化维护这些条目。
进程名给的是搜索活动的线索，不能直接看出是哪一个 App 引起的，如果忙的是 mds、mds_stores 或 mdworker，可以接着看 Spotlight 文件索引排查，Core Spotlight 服务繁忙和 Spotlight 找不到文件，是两个需要分开验证的现象。
在相同的工作状态下比较两次
在活动监视器中选择「显示 › 所有进程」，打开 CPU 页搜索 corespotlightd，记下 CPU 占用，再看磁盘活动，比较时尽量保持同样的工作状态，不把正在导入的 Mac 和休眠后的 Mac 放在一起比。
- 记下高占用之前发生了什么，比如 App 更新、新资料库导入或 macOS 更新。
- 导入或同步还在推进时，先让它完成，不同资料库没有统一的完成时限。
- 保存工作，正常退出一个怀疑相关的 App，再观察进程，条件允许时重新打开同一个 App 做一次对照。
- 如果每次打开它都会复发，检查 App 更新和它官方提供的搜索、索引设置，一次只改一个因素。
退出 App 后占用下降，能支持两者有关，还不能证明数据库损坏，后台任务也可能在窗口关闭后继续，所以一次读数没变同样不能排除这个 App，不要把一串无关服务全部强制退出。
持续繁忙时留下诊断信息
选中进程，在活动监视器的「更多」菜单里使用「取样进程」，Apple 的诊断指南说明它会采集三秒内的信息，也提供「“聚焦”诊断」来收集搜索相关信息。
把 macOS 版本、App 版本、大致开始时间和能再次触发高占用的动作一起保留，取样里有调用栈，但一个函数名不能直接定原因，发送前检查报告内容，通过私下渠道交给 Apple 支持或相关 App 的开发者。
确认哪一种搜索坏了，再决定修哪里
如果 Spotlight 找不到普通文件，Apple 的重建流程是在「搜索隐私」或「Spotlight 隐私」里按说明添加、再移除出问题的文件夹或磁盘，名称随 macOS 版本变化，这会主动重新索引，不是所有 corespotlightd 高 CPU 都适用的修复。
如果只是某个 App 的内容搜不到，先走它官方提供的修复流程，不把删除隐藏的 Core Spotlight 数据库、删除 App 文档或关闭全部搜索当作第一步，现象从系统更新后开始时，也可以结合 macOS 更新后变慢的排查，确认忙的是索引还是其他任务。
常见问题
corespotlightd 是恶意软件吗？
这个名字与 macOS 搜索活动有关，但名字不能证明可执行文件的身份，怀疑来源时要核对实际路径和签名信息，不只凭标签信任它，也不只凭标签删除文件。
清缓存能解决它的 CPU 占用吗？
不一定，清缓存不能说明哪个 App 在提交搜索内容，也解释不了任务为什么反复发生，先对照 App 的行为并保留进程取样，再选择对应的修复。