Mac 变慢了，应该如何排查

Mac 变慢，就是延迟在增加。CPU 争用、内存压力、存储容量、磁盘读写、散热限制或网络服务变慢，都可能造成相似的体感。排查时要在卡顿发生的当下找出哪项资源已经饱和，等问题结束后再截一张状态图，几乎说明不了什么。

下面会解释这些指标怎样工作，以及如何用命令查看它们。

关于内存的误区：空闲越多并不是目标

最常见的错误反应，是看到「可用内存」很少就开始紧张。在 macOS 中，空闲内存偏低通常既正常又健康。未被利用的内存没有价值，所以内核会主动用它缓存近期文件，让下一次读取更快；应用真正需要空间时，这些缓存会立即释放。

macOS 还会压缩内存。自 OS X Mavericks 起，内存逐渐填满时，系统会先在原位压缩不活跃页面，而不是立刻把它们写到更慢的交换空间。可以直接观察这些计数：

vm_stat

数值以页面为单位，页面大小显示在输出顶部附近。值得关注的不是 Pages free，而是内存压力和变化速度。Swapins 与 Swapouts 是开机以来的累计值，一个很大的总数不能证明当前正在发生问题。在卡顿期间运行两次命令观察增量，或在「活动监视器」中查看交换空间与压力是否持续上升。

最有用的总览，是「活动监视器」内存页底部的内存压力。Apple 的内存说明把绿色定义为内存使用高效，黄色表示可能存在压力，红色表示需要更多内存。应把这张图与交换空间趋势和应用列表一起看，而不是只看空闲内存。

找到瓶颈在哪里

可以按顺序查看「活动监视器」的各个页面，也可以使用终端：

• CPU： 在终端运行 top -o cpu，或在「活动监视器」CPU 页按占用排序。%CPU 按核心计算，所以进程超过 100% 代表同时使用多个核心。构建或导出任务出现这种情况很正常，空闲应用长期如此才值得调查。
• 内存： 查看前面提到的内存压力图和交换空间趋势。
• 磁盘容量： 运行 df -h /。APFS 需要可用空间保存交换数据和临时文件，容量接近耗尽会阻止更新，也可能让任务没有足够的临时空间。没有适合所有人的安全百分比，应把实际可用容量与失败任务所需空间进行比较。如果这里是瓶颈，先找出占满磁盘的文件，再安全释放空间。
• 磁盘读写： 在「活动监视器」磁盘页按写入字节数或读取字节数排序，并在卡顿出现时观察曲线。iostat -w 1 可以提供实时命令行视图。同步、备份、构建或故障外置硬盘，都可能在容量充足时造成延迟。
• 温度： 见后文。
• 网络或服务延迟： 如果只有一款依赖云端的应用变慢，而本地应用仍然流畅，先查看它的网络活动和服务状态。不是每一次等待都来自 Mac 硬件瓶颈。

这些读数能区分全系统瓶颈与单个应用变慢。泛化的一键清理会同时改变多个变量，反而可能掩盖原因。

失控的进程

CPU 长时间满载时，top -o cpu 会把主要进程放在最上方。常见原因包括应用卡死、同步客户端重复扫描，或后台辅助程序陷入循环。如果确认可以安全结束，就正常退出它。

如果进程几秒后自行重启，通常有 launchd 任务或登录项在维持它。只结束进程不会持久生效，应继续检查启动项。

处理系统进程要格外谨慎。kernel_task 占用升高，常常是系统在芯片过热时主动占用 CPU 时间，以限制其他任务继续发热。它是散热症状，不是应该强制结束的普通应用。

散热降频

Mac 过热时，芯片会降低时钟频率来降温，高负载工作因此变得迟缓。可以先确认，而不是猜：

pmset -g therm

在 macOS 提供相应字段时，这条命令会显示已记录的散热和性能警告状态。需要一次包含功耗与散热压力的详细样本时，运行：

sudo powermetrics --samplers thermal,cpu_power -n 1

比较相同工作负载下的趋势，不要把某个温度当作适用于所有机型的统一上限。如果瓶颈是降频，解决方向是减少负载、改善通风或维修，不是清缓存。风扇声可以作为辅助证据，但无风扇 Mac 同样会降频。MacBook 风扇为什么很响会进一步说明排查方法。

Spotlight 和登录项

还有两类后台原因值得排除。macOS 更新、迁移或大量移动文件后，Spotlight 可能重建部分索引。mdutil -s / 只能说明索引是否开启，不能证明此刻是否正在重建。持续的 mds 或 mdworker CPU、磁盘读写和 Spotlight 进度界面，放在一起才有意义。

索引持续时间取决于数据量、存储速度、权限和文件是否持续变化，因此不存在可靠的「一小时一定结束」承诺。

另一类原因是启动负载。「系统设置 > 通用 > 登录项与扩展」会把登录时打开的应用与允许后台运行的软件分开显示。它们背后可能使用 Service Management、launchd、扩展或应用辅助程序。一次只关闭一个身份明确的项目，并确认所属应用仍能正常工作。

监控工具怎样读取这些数据，又不成为新的负担

这一节可以跳过，但它能解释前面的内存判断为什么成立，也能说明实时监控为什么不应该成为另一个高负载进程。Mole 的开源命令行版中 cmd/status 与原生 Mac 应用使用彼此独立的采集器，不过两者都会把快速指标和较慢的补充信息分开处理。

命令行版会解析 vm_stat 中基于文件的页面数，再乘以系统报告的页面大小，补上跨平台指标库在 macOS 上无法提供的缓存内存。它读取 memory_pressure 的系统压力状态，而不是根据空闲字节数自行推算。原生应用则不调用外部命令，直接通过 host_statistics64 读取 VM 计数，并通过 kern.memorystatus_vm_pressure_level 获取压力等级。

保持轻量是另一半。监控器如果每次刷新都重新测量所有内容，本身就会变成性能问题。因此采集器按不同频率分层：

CPU、内存和网络等低成本指标大约每秒刷新一次。进程、GPU 和磁盘补充信息只在较重的刷新周期运行，硬件与设备探针则复用更长时间的缓存。固定大小的历史只保留绘制趋势线所需的近期样本。这样，菜单栏 HUD 可以实时更新，又不会变成你正在诊断的负载。

工具能节省什么

前面的数据都能通过系统命令读取，诊断 Mac 变慢并不要求安装应用。工具节省的是把证据拼在一起的时间。Mole「状态」页会在一个页面展示 CPU、内存压力、磁盘、温度和高占用进程，并在菜单栏提供实时读数。点击进程还能查看它由什么启动、是否阻止 Mac 休眠，以及正在读取和写入什么。

它只是对系统命令的整合，不能取代对指标的理解。无论使用什么工具，都要避开会同时改变无关状态的「一键加速」。把有用的文件缓存强行赶出内存，无法创造持久性能提升。重启可以帮助诊断卡住的进程，也是部分更新的必要步骤，但 macOS 本来就在持续管理内存和交换空间。

按这个顺序排查

先复现卡顿，同时观察 CPU、内存压力、磁盘容量、磁盘读写、散热状态和网络活动。然后只改变一个变量，在相同工作负载下再次测量。

这样可以把「Mac 感觉很慢」变成一个可验证的原因，也能避免把重启或清理带来的短暂变化误认为永久修复。