你打开活动监视器，因为 Mac 感觉变卡了——风扇呼呼响、硬盘指示灯一直闪——CPU 列最顶端的进程是 mds_stores，常常 100%、200%，甚至更高。杀掉它感觉不太对；干等又觉得浪费时间。和一个行为异常的应用不一样，这可能是一项正在进行的合法工作——也可能是卡住了。本文教你清晰地区分这两种情况，并梳理真正管用的那些办法。
快速结论
mds_stores 是 Spotlight（macOS 的搜索索引）的”按卷工作”进程。高 CPU 通常代表真正在干活：刚装好系统或刚升级后的首次索引、新插入的外接硬盘、云盘同步带来的文件搅动，或者开发流程批量生成成千上万个小文件。有三个信号说明它是卡住了，而不是在工作：
- 同一个卷上已经持续运行超过 24 小时，进度毫无变化。
- 没有任何近期触发源——没有云盘同步在跑、没有正在进行的大规模文件拷贝、也没有刚挂上去的硬盘——但 CPU 和磁盘还是持续高位好几个小时。
- 它反复在同一批文件上来回扫。
ProcXray 的 Open Files（打开文件）面板可以直接告诉你 mds_stores 此刻正在读哪些文件路径——是定位触发源最快的方式。活动监视器的进程检查器（Inspector）确实也能列出一个进程打开的文件，但是是一个不能搜索、没有历史记录的静态对话框——面对几千条索引路径要实时筛选时，ProcXray 的面板能在几秒内把诊断做完。
mds_stores 是什么？
mds_stores 是组成 macOS Spotlight 的三个进程之一：
mds—— 元数据服务器的协调进程，位于/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mds。整个系统只有一个。mds_stores—— 每个被索引的卷一个进程，负责持有该卷在磁盘上的索引存储。你的内置 SSD 有一个；每个被索引的外接硬盘也有一个；某些被启用了索引的网络挂载也会有自己的一个。mdworker_shared（有时叫mdworker）—— 工作进程，负责打开单个文件，提取其中的元数据（文本、EXIF、ID3、文档属性等），再把结果交回给mds_stores。
如果你在活动监视器里看到多个 mds_stores 进程，那是正常的——只是因为不止一个卷在被索引。一台空闲、索引已经构建完毕的 Mac，其 mds_stores 通常只占 0–5% CPU。按卷拆分进程的设计也意味着：外接硬盘的 mds_stores 可以独立飙高，而完全不影响系统盘那个。
关于百分比的提示：在活动监视器里，100% 意味着等同于一个完整的 CPU 核心。在多核 Mac 上，单个进程的数字可以远超 100%。所以 mds_stores 显示 250%，意味着它正在占用大约两个半核心。
关键视角：在工作 vs 卡住
这是本文最重要的视角转换。和 WindowServer 不一样——后者总是下游被其他应用驱动的——mds_stores 占用 CPU 通常意味着索引器确实在干正经事，而正经事是有终点的。所以诊断时要问的不是”mds_stores 哪里坏了？“而是：
这是会结束的临时索引，还是索引器卡住了？
简要的判断标准：
- 大概率是在工作（等）：在一个已知事件之后开始（系统更新、大量文件拷贝、外接硬盘挂载、大规模
git pull）；CPU 高但在几分钟到几小时内有下降趋势；mdutil -s报告索引正在进行中。 - 在工作但偏慢：后台有云盘同步软件在跑；或者你有一个文件夹塞满了不断变化的小文件（编译产物、日志目录、邮箱）。
- 大概率卡住了（动手）：已经跑了超过 24 小时；
mdutil报告索引已完成；进程一直在同一批文件上来回扫；或者刚杀掉它马上又重新飙高。 - 大概率是索引损坏（动手）：刚刚经历过强制关机、内核 panic 或 APFS 卷修复。
这套标准支撑了后面的整个流程：识别触发源、判断是否会自己结束、然后采取对应的措施。
哪些情况会触发 mds_stores 飙升
六种常见触发，大致按出现频率排序：
1. 全新安装或 macOS 升级
第一次给一个卷建索引时，Spotlight 要从每个文件中提取元数据。在刚刚装好的 Mac 上，这通常需要 30 分钟到几小时，取决于个人目录大小、照片和文档数量。重大版本升级有时也会触发部分重新索引。
2. 新接入的外接硬盘，或一次大规模文件拷贝
每个新文件都要提取元数据。挂载一块装满混合内容的 1 TB 外接硬盘，可以让 mds_stores 忙一到几小时。往系统盘里大规模拷贝——比如从备份还原一个文件夹——也是同样的效果。
3. 云盘同步带来的文件搅动
这是”mds_stores 永远停不下来”最常见的单一原因。iCloud 云盘、Dropbox、OneDrive、Google Drive、Box 都会在后台创建、修改、删除文件。每一个改动都是 Spotlight 必须跟进的文件系统事件。两个模式尤其臭名昭著：iCloud 的 优化 Mac 储存空间（会驱逐并重新下载文件），以及 OneDrive 的 按需文件（思路一样）。每一次驱逐/重新下载循环，都会让对应的文件被重新索引。
4. 开发流程批量生成成千上万个小文件
npm install / yarn install（那个臭名昭著的 node_modules）、Xcode 写入 ~/Library/Developer/Xcode/DerivedData 的编译过程、对大分支的 git checkout、Docker 镜像解压、Homebrew 更新，都会一次性产生大量文件系统事件。Spotlight 会试图全部索引。
5. Time Machine 首次备份或大型快照
Time Machine 与 Spotlight 共用同一套文件系统事件流。首次备份或大型快照操作有时会和 mds_stores 互相纠缠，让两者一起飙高。
6. 索引损坏需要重建
经历过强制关机、内核 panic、APFS 卷问题、或失败的磁盘修复之后，Spotlight 索引可能会变得不一致。mds_stores 这时会从头重建索引——表面上和首次索引一样，但发生得毫无征兆。
几个值得点名的常见搅动源：Adobe Creative Cloud 同步、Backblaze、Carbon Copy Cloner，以及任何会做实时扫描的杀毒软件。如果你装了其中之一，先怀疑它。
怎么判断它会不会自己结束
活动监视器是自然的起点，但它显示打开文件的界面是个不能搜索、没有历史的静态弹窗——而最常破案的细节恰恰是：mds_stores 此刻正在读哪些文件路径，并且这些路径随时间的变化情况。
第 1 步：确认索引是否启用
打开终端，运行：
mdutil -s /输出会是以下之一：
Indexing enabled—— 这个卷的 Spotlight 索引功能已启用Indexing and searching disabled—— 索引被关闭；在这种状态下出现高 CPU 才不正常Error: unknown indexing state—— 索引状态异常；这是一个强烈的”该重建了”信号
对每一个卷都重复执行（mdutil -s /Volumes/External）。
重要提示：mdutil -s 只告诉你这个卷上 Spotlight 索引功能是否启用，它不报告进度、也不直接告诉你索引是否正在推进。要回答”它还在向前推进吗？“这个问题，必须结合：第 2 步里活动监视器的磁盘读取趋势、第 3 步里 Open Files 面板中文件路径是否在变化、以及打开 Spotlight 搜索框时顶部是否还显示”正在索引……”的状态条。
第 2 步：在活动监视器里做粗筛
CPU 标签页 → 按 CPU 排序，确认 mds_stores 在最顶端。切换到磁盘标签页 → 按读入字节排序。如果 mds_stores 占据了磁盘读取的大头，那它正在扫描文件（这就是索引的样子）。盯五分钟——CPU 是在下降、持平，还是上升？
第 3 步：用 ProcXray 找出它在索引什么
ProcXray 就是为这种跨资源诊断打造的：
- Open Files（打开文件）面板直接展示
mds_stores当前打开的所有文件路径。这是本场景的杀手锏。如果这些路径集中在~/Library/Mobile Documents/下，那就是 iCloud 触发；在~/Dropbox/或~/OneDrive/下，对应的就是相应的云盘；在node_modules/或DerivedData/下，那就是开发流程。 - Resource History（资源历史）让你能回溯几小时的 CPU 和磁盘 I/O 曲线。下降趋势意味着它会结束；触发事件已经过去之后却长时间保持高位平直，意味着卡住了。
- 逐进程 I/O 列让你按磁盘读写排序所有进程，确认
mds_stores确实是 I/O 主导者，而不是巧合。 - Process Tree（进程树）视图展示
mds→mds_stores→mdworker_shared的层级，让你看清工作进程是真的在干活，还是闲着不动。
关于活动监视器在这类调试中的其他短板，参见 ProcXray vs 活动监视器对比。
第 4 步：通过移除可疑触发源做 A/B 测试
一旦有了假设，就一次拔一块外接硬盘看看。逐个暂停云盘同步软件。退掉编译工具。每做一次改动后盯着 mds_stores 看一分钟。一次明显的下降，就能在不重启、不打断整个会话的前提下确认原因。
分步骤的解决办法
按顺序执行——从代价最小、最不打扰人的开始。
1. 第一次观察时，先等 30 分钟到 2 小时
最容易被忽视的修复方法。大多数索引会在这个窗口内完成。给 Mac 接上电源让它跑。回来时索引已经完成，是绝大多数情况下正确的结果。
2. 把元凶文件夹加入 Spotlight 搜索隐私
系统设置 → Spotlight → 搜索隐私（Search Privacy） → 把文件夹拖进去。Spotlight 会停止索引它。最值得排除的文件夹：
node_modules目录- 编译产物（
build/、dist/、target/，以及 Xcode 的DerivedData） - 临时目录、日志目录、那些你从来不搜的大型归档目录
代价：这些文件夹里的文件无法通过 Spotlight 搜索到。对于编译产物和 node_modules 来说，这几乎一定是正确的选择。
3. 临时暂停云盘同步
如果 Open Files 面板显示 mds_stores 在读 iCloud、Dropbox、OneDrive 或 Google Drive 的目录，先暂停那个软件。如果 mds_stores 在几分钟内安静下来，你就确认了原因。长期方案是：要么接受这个索引开销，要么通过”搜索隐私”设置把云盘目录排除在 Spotlight 之外。如果 iCloud 的”优化 Mac 储存空间”开着、而你磁盘空间够用，考虑关掉它——那种不断驱逐再下载的循环，是死循环最常见的根源。
4. 在某个卷上禁用索引
对那些你不会通过 Spotlight 搜索的外接硬盘（比如临时盘、媒体素材归档盘）。不要在 Time Machine 备份盘上禁用索引——Time Machine 依赖该卷上的 Spotlight 索引才能正常工作。
sudo mdutil -i off /Volumes/External之后用 sudo mdutil -i on /Volumes/External 再开回来。
5. 索引损坏时强制干净重建
如果 mdutil -s 报告 “unknown indexing state”，或者你已经排除了所有触发源但 mds_stores 还在转，就清空并重建索引：
sudo mdutil -E /预计要 30 分钟到几小时的高 CPU 和磁盘活动——这就是重建本身，不是问题。在你确认了索引损坏之后再用，不要把它当作”第一反应”。
6. 最后手段：直接杀掉 mds_stores
macOS 几秒钟内就会干净地重启它。这不会修复触发源，但能打断一个失控循环、让你有时间调查。从活动监视器的”强制退出”做，或者：
sudo killall mds_stores不推荐：用 sudo mdutil -a -i off 永久禁用 Spotlight。你会失去 Spotlight 搜索、邮件搜索，以及任何依赖底层元数据 API 的应用。几乎不会是正确的方案——优先通过”搜索隐私”设置排除嘈杂的文件夹。
如果 mds_stores 不是唯一的可疑对象、需要做更广泛的性能排查，参见 如何通过杀掉合适的进程来修好慢吞吞的 Mac。
常见问题
杀掉 mds_stores 安全吗？
安全。macOS 会在几秒内自动重启它。杀掉它会中断它当前的工作，但不会损坏索引或你的数据。要注意的是：如果杀掉之后同样的工作负载马上又把它再拉起来，那就说明你什么都没修——只是确认了原因是持续性的，需要从上面列表里挑一个真正的修复方案。
正常索引需要多久？
刚装好的 Mac 首次索引：通常 30 分钟到 2 小时，超大个人目录可能要 4–6 小时。新挂载的 1 TB 外接硬盘：大致与文件数量成正比，往往 1–4 小时。云盘同步爆发后的索引：几分钟。在文件状态稳定的情况下，持续超过 24 小时是不正常的，提示要么是卡住了，要么有一个失控的搅动源。
为什么 mds_stores 反复对同一批文件重新索引？
几乎一定是某个云盘同步软件或备份工具在反复触碰这些文件。iCloud 云盘的优化 Mac 储存空间是常见元凶——它会驱逐和重新下载文件，每一个循环都让 Spotlight 重新索引一遍受影响的文件。检查”系统设置 → [你的名字] → iCloud → iCloud 云盘 → 优化 Mac 储存空间”。如果磁盘空间够用，把它关掉，往往能解决这种死循环。
我应该永久禁用 Spotlight 吗？
不要——除非你有非常具体的理由，并且不用 Spotlight、邮件，以及任何系统级搜索功能。很多应用都依赖底层的元数据 API，禁用 Spotlight 影响的远不止那个放大镜图标。通过”搜索隐私”设置排除嘈杂文件夹，能用极低的代价拿到大部分好处。
为什么 mds_stores 在吃磁盘，但 CPU 却不高？
索引大量是 I/O 密集型的。mds_stores 大部分时间花在从磁盘读取文件内容上，CPU 只有短暂的爆发用来解析元数据。高磁盘 + 低 CPU 是正常索引的特征。如果 CPU 也高，那说明索引器在处理大量小文件——node_modules、邮箱、git objects 都是典型场景。
参考资料
- Apple 官方支持 —— 在 Mac 上更改聚焦设置
man mdutil（macOS 内置 man 文档）——mdutil命令官方参考- Mac 上 WindowServer 占用 CPU 过高
- Mac 上 kernel_task 占用 CPU 过高
- ProcXray vs 活动监视器对比
- 如何在 macOS 上监控进程：完整开发者指南
免费下载 ProcXray → —— 看到 mds_stores 此刻正在索引哪些文件。支持 macOS Sonoma+、Apple Silicon 和 Intel。