# 如何安全做 Mac 系统维护

> 分清系统自动完成的维护和仍需人工的修复，避免不必要的 Launch Services 重置和盲目重建，并要求工具说明跳过原因。

Published: 2026-08-01 | Updated: 2026-08-22

「做 Mac 维护」这个话题至今仍会引出十年前的建议：每周清缓存、强行重建 Spotlight、彻底重置 Launch Services，或者点一下第三方工具里的「系统优化」按钮，而现代 macOS 早已按自己的节奏把大量这类工作做完了。真正有用的维护应该范围窄、有证据、也能回退，看不出理由的按日历大清理通常没有意义，有时只是图个心安。

更广的预防清单（备份与更新优先）见[Mac 维护清单](https://mole.fit/zh/blog/mac-maintenance-checklist)，这里只讲系统已经在做什么、哪些手工动作仍然有用、哪些做法已经不适合当前的 macOS，读完后应该能说清症状、一次只改一类东西，并量出改动到底有没有用，而不是凭感觉再跑一轮。

**短答案**：现代 macOS 几乎不需要仪式性保养；有症状再做对应动作：搜索结果不对才重建 Spotlight 索引，某个 app 异常才清它的缓存；purge 脚本和内存清理器直接跳过，系统本来就在管理这两件事。

## 「维护」曾经指什么，现在变了什么

旧文假设：

- 字体缓存与 dyld 缓存被当成需要定期手动删除的东西，不删就会越积越脏
- Spotlight 索引要按日历定期重建一遍，不管搜索结果是不是真的出了问题
- Launch Services 需要 `lsregister -kill` 式的核弹级重置，不彻底重来一遍就觉得不放心
- 空闲内存越多越好，空闲的多少本身就被当成了维护目标，内存越空越安心

在当前 macOS 上：

- **可清除存储与本地快照**会在磁盘压力下自动变薄，不用人催（[快照](https://mole.fit/zh/blog/how-to-delete-local-time-machine-snapshots-mac)）
- **内存缓存**是系统有意用掉的，活动监视器里的内存压力比空闲 RAM 的多少更能说明问题
- **软件更新**是最主要的安全维护路径，这一项任何清理工具都插不上手
- **后台索引**会在大量导入之后自行平息下来，不需要人工干预（[mds / mdworker](https://mole.fit/zh/blog/mds-mdworker-high-cpu-mac)）

如果机器响应正常、磁盘已加密、备份在跑、可用空间也充足，那么什么都不做本身就是一种合理的维护，不需要专门安排一个「维护日」。

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/macos-auto-vs-gaps.webp" width="1360" height="454" loading="lazy" alt="自动回收、归属审核与诊断分列三栏">
  <figcaption>让系统回收它负责的部分，对应用自有文件做归属审核，把不透明问题当作诊断，而不是每周一键清理。</figcaption>
</figure>

把更新和快照留给它们的系统入口。Apple 的[软件更新说明](https://support.apple.com/108382)覆盖 macOS 更新，[本地快照说明](https://support.apple.com/102154)则说明快照会自动管理并计入可用空间。它们都不是每周维护脚本应重复执行的动作。

## 有理由时再做的合理维护

### 1. 更新与安全姿态

在可信的网络上安装 macOS 与 App Store 的安全更新，浏览器和其他处理不可信内容的软件也要保持更新，大版本升级之前先确认 FileVault 已开、备份是真的**测过**的，清理工具替代不了补丁，这一点没有例外。

### 2. 启动与后台负载

登录慢多半是登录项太多，而不是字体缓存脏了，处理时一次只动一个所有者，逐项检查[启动项与后台项目](https://mole.fit/zh/blog/how-to-disable-startup-programs-on-mac)，并且优先禁用而不是删除，删错了连恢复的入口都没有。先分清四类东西：

- 在系统设置里直接可见、也最容易自己动手处理的登录项，一般从这里开始
- Service Management / BTM 管理的后台项目
- 有真实 plist 文件的 launchd agent / daemon
- 应当保持只读、不要去碰的受保护厂商组件和 Apple 自带组件，这一类不要动

### 3. 按归属处理磁盘容量

可用空间不足时：

1. 先用存储设置、`df` 与文件夹地图把大头量出来（[大文件](https://mole.fit/zh/blog/how-to-find-large-files-on-mac)），知道空间去了哪再动手
2. 再清理那些能叫出名字、说得出属于谁的[缓存](https://mole.fit/zh/blog/how-to-clear-cache-on-mac)，叫不出名字的先放一放
3. 如果本地快照把已删除的数据钉住了，就把快照变薄，让空间真正回来
4. 退役应用时顺手做一次[卸载卫生](https://mole.fit/zh/blog/how-to-completely-uninstall-apps-on-mac)，别把残留留给下一次大扫除时再头疼

### 4. DNS 与路由表（两件不同的工具）

遇到解析器异常或者 VPN 故障之后，刷新一次 DNS 缓存可能就有帮助，命令是：

```
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
```

这一步清掉的只是解析器缓存，并**不会**重建路由表，两件事看起来都像「刷网络」，其实不要混为一谈。

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/dns-vs-route-flush.webp" width="1360" height="454" loading="lazy" alt="刷新 DNS 只清解析结果；刷新路由表可能打断 VPN 与系统代理">
  <figcaption>DNS 刷新与路由刷新是两件工具。隧道或系统代理活跃时，后者杀伤面很大。</figcaption>
</figure>

刷新路由（`route -n flush` 一类）的风险要大得多，可能直接打断进行中的 VPN 隧道和系统级 HTTP/SOCKS 代理，而且只设置了系统代理的客户端可能根本**没有** `utun` 接口，所以「看不到 VPN 接口」并不能证明刷新路由是安全的。维护工具在 VPN 或代理活跃时应该明确说明为什么跳过，而不是强行显示一个成功，把风险藏在动画后面。

### 5. 快速查看、图标服务与用户级缓存

预览卡住或缩略图损坏之后，重建**用户级**的快速查看或图标缓存可能有用，但要优先选文档化的、用户范围的重置方式，不要去乱删系统目录。动手前先退出正在使用这些预览的应用，缓存回填期间第一次预览会变慢，这属于预期现象，不用紧张，也不用再清第二次。

### 6. 进程与散热诊断

发热、风扇狂转和失控进程不是靠删偏好设置能修好的，先用活动监视器看清楚负载到底在哪，再对照[变慢](https://mole.fit/zh/blog/why-is-my-mac-so-slow)、[kernel_task](https://mole.fit/zh/blog/kernel-task-high-cpu-mac) 与[温度](https://mole.fit/zh/blog/how-to-check-mac-temperature) 这几篇逐项排查。

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/maintenance-cadence.webp" width="1360" height="454" loading="lazy" alt="备份与更新优先，其次存储与启动，深层重置最后且少做">
  <figcaption>节奏很重要：备份与更新是常规；深层索引重建只应是对已诊断故障的例外响应。</figcaption>
</figure>

## 何时该重建 Spotlight（何时不该）

重建整个元数据存储的代价很高，动辄是数小时的 CPU 占用、发热和耗电，换来的常常只是心理上的新鲜感，所以只在以下情况才值得考虑：

- Spotlight 在理应被索引的卷上系统性地找不到明明就在那里放着的已知文件
- 底层的磁盘问题已经修好之后，`mdutil -s` 仍然显示卡在原地或者已经失败
- 已经排除掉排除列表、网络卷与隐私设置这些常见的干扰因素之后，再动手

先查状态：

```
mdutil -s /
```

不要为了「性能」每月重建一次，系统升级或大量导入照片之后出现的索引尖峰，常常是正常的追赶而不是损坏，等它自己跑完就好，判断方法见 [mds 与 mdworker](https://mole.fit/zh/blog/mds-mdworker-high-cpu-mac)。

## 维护表演：默认跳过

| 动作 | 为何不宜作为默认 |
|---|---|
| 每周定时清扫「垃圾」 | 删掉的是健康缓存，还会增加 I/O 与更慢的首次启动 |
| `lsregister -kill` 式 Launch Services 核弹 | 附带伤害太大，只保留窄范围、有文档的重建方式 |
| 盲目全量重建 Spotlight | 付出数小时 CPU，只应在真正索引故障之后做 |
| 把清字体缓存当成万能药 | 字体缓存很少是真正的根因 |
| 关掉 SIP 来「清得更干净」 | SIP 是安全边界，不是一个维护开关 |
| 改写未知 plist 的「加速」工具 | 没有性能理论就丢掉偏好设置 |
| 付费才能看恐吓式扫描结果 | 这是[销售流程露出的破绽](https://mole.fit/zh/blog/what-mac-cleaners-should-never-delete) |

如果一篇文章说不出它要修的故障模式是什么，那它给出的就不是维护建议，只是维护表演，可以直接关掉。

## 实例：「出差回来机器变慢」

症状是这样：登录后风扇转个不停、第一次打开应用很慢，而磁盘其实并不满。

基线：

```
df -h /
# Activity Monitor: Memory pressure, CPU top processes
```

看到的画面是这样的：磁盘还有 80 GB 空闲，内存压力只在登录后黄一分钟，登录项里躺着三个聊天应用、两个更新器和一个云同步。

只改一类：禁用两个不再用的登录项，外加一个本来就会手动打开的更新器，然后重启，用同一条路径计时打开应用。如果好转就停手，不要在同一个下午再去清缓存、重建 Spotlight、刷新路由，否则根本学不到到底是谁帮了忙，下次也无从复现。

## 如何安全跑一批维护

1. **说清症状**，到底是磁盘满、预览卡住、DNS 异常还是登录慢，一次只认领一个去处理
2. **记录基线**，比如 `df -h` 的空闲空间、活动监视器的一次采样，或者给启动过程计个时
3. **一次只改一类东西**，改完测完确认有效再动下一类，不叠加
4. **用同样的负载复测**，换了负载前后就失去可比性，等于白测
5. **留下记录**：跑了什么、跳过了什么、失败的是什么，都写下来

好的辅助工具应该展示**已运行 / 已跳过（原因） / 失败**三栏，而不是只放一个成功动画，为了保护 VPN 会话或进行中的安装而跳过，并不是失败，而是工具在说实话。

## 维护工具的边界

维护工具适合把边界清楚的任务放进一次可审核的运行里，比如用户级快速查看重建、选定的缓存和元数据工作；需要授权的任务应明确说明用途，不安全或不适用时应给出跳过原因，比如 VPN 或系统代理活跃时就不要动网络栈。它们替代不了软件更新，替代不了 Time Machine 备份，也替代不了恶意软件响应，别指望一个按钮包打天下。

磁盘候选用清理，应用与启动项用软件管理，实时指标用状态监控；确实需要有边界、结果可见的维护回合时，再使用维护工具，用完就停。

## 常见错误

**因为日历写着「维护日」就清**：维护需要说得清的理由，日历本身不算理由，清掉的往往是系统马上又要花代价重建的东西。

**把 DNS 刷新当成路由刷新**：两者的杀伤面完全不同，前者只清解析结果，后者可能直接打断正在用的 VPN 与代理。

**因为「感觉慢」就重建 Spotlight**：先把 CPU 与磁盘量出来再说，几个小时的重建换不回一个没被诊断过的问题。

**没有基线就连做五件事**：最后学不到任何东西，也不知道到底该保留哪一项、回退哪一项。

## 决策规则

为说得清的理由而维护，动手之前和之后各测一次，优先走 Apple 自己的更新与备份路径，而不是第三方工具的深度清洁。工具确实有帮助时，要求它提供路径级审核、可恢复的文件操作，以及诚实的跳过记录，做不到这三点的工具就不要把维护交给它。

## 操作顺序

1. 先给症状起一个说得出口的名字，再把基线指标写下来
2. 若是为了安全或升级做准备，先更新系统并确认备份可用
3. 症状对得上号时，再去改启动项或者腾空间，对不上就先别动
4. 仅在解析器出问题时才刷 DNS；有 VPN 或代理活跃时跳过路由刷新
5. 深层重建只留给已经诊断过的故障，平时不做预防性重建
6. 用同一个指标复测，只保留真的有用的改动，其余的回退掉

## 延伸阅读

- Apple：[更新 macOS](https://support.apple.com/108382)
- Apple：[关于 Time Machine 本地快照](https://support.apple.com/102154)
- [维护清单](https://mole.fit/zh/blog/mac-maintenance-checklist)
- [加速 Mac](https://mole.fit/zh/blog/how-to-speed-up-mac)
- [为什么会变慢](https://mole.fit/zh/blog/why-is-my-mac-so-slow)
- [mds / mdworker](https://mole.fit/zh/blog/mds-mdworker-high-cpu-mac)

Mac 不需要按周做一轮「清理仪式」，留出足够的可用空间、及时安装更新，遇到明确症状再做针对性的修复，对大多数机器来说就已经够了。


## 维护日记模板（可复制）

不用任何专门工具，在备忘录里留六行记录就够了，格式如下：

```
日期：
症状：
基线：（df / 启动秒数 / 进程名）
改动：只写一类
复测：
结论：保留 / 回退
```

两周后回看一眼就会发现，真正有效的往往就是更新、减少登录项或者腾出磁盘空间这几件事，没有什么玄学，也不需要仪式感。

## 何时该停手

出现以下情况时，就该停止脚本式维护了，改去查硬件或评估重装：

- 磁盘健康报告里出现失败，或者卷反复被系统卸载掉
- 无负载时持续高温与 kernel_task 高占用，且已排除灰尘与外壳遮挡这些因素
- 内存压力长期红色且交换剧烈，同时应用本身存在已知的内存泄漏

维护工具修不了坏盘，也替代不了有针对性的应用更新，到了这一步，该送修就送修，别再用脚本安慰自己。

## 与清理、优化、状态三个面的分工

- 找出磁盘候选、列出可清缓存这类事，归「清理」页管
- 应用清单、更新检测与启动项这类事，归「软件」页管
- 有边界、可审核的系统维护回合这件事，归「优化」页管
- 实时负载与风扇这类持续指标，看「状态」页和菜单栏就够

同一天把四类操作都做一遍，通常就判断不了到底是哪一步起了作用，所以按症状选一种处理方式就好，别贪多，也别追求仪式感。

## 常见问题

### 需要定时跑清理或保养工具吗？

不需要；定时清理删掉的大多是系统还会复用的可重建文件，系统随后还要花 I/O 和电量把它们重建回来；有症状、说得出要修什么的时候，再做对应的那一项就够了。

### 重建 Spotlight 索引能让 Mac 变快吗？

它只修复搜索结果错误或缺失这一类问题，不会加速其他任何事情，而且触发之后几个小时的后台索引，反而会先把机器短暂拖慢一阵子。

### 内存清理器和 purge 脚本值得用吗？

不值得；macOS 自己管理内存压力和文件缓存，强行释放只是丢掉热数据，下一个动作还得重新从磁盘加载回来，体感反而更慢，看不出任何好处。

---

Canonical HTML page: https://mole.fit/zh/blog/how-to-run-mac-maintenance-safely
Blog index for agents: https://mole.fit/zh/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
