WorkBuddy系统诊断优化实录

用 WorkBuddy 给一台 11 岁 MacBook 做系统诊断：揪出 4 个"僵尸启动项"，释放 3.8GB 缓存 #WorkBuddy

一台 2015 款 MacBook Pro，开机越来越慢。我没有急着装清理软件，而是让 WorkBuddy 先做了一次只读诊断——结果发现问题根本不在硬件老化，而藏在启动配置里。

任务卡：这次到底干了什么

一、起因：先别急着"清理"

手头这台 MacBook Pro（MacBookPro12,1，Early 2015，双核 i5 + 16GB，macOS 12.7.6 Monterey）服役了 11 年，最近的症状很典型：开机要等很久，进桌面后还要卡一阵。

常见的做法是装个清理工具一键扫。但我更想知道慢在哪里——盲目删除缓存只能换来几天爽感，启动项才是开机速度的决定性因素。

所以我给 WorkBuddy 的指令是：

按最优的方式，优化本电脑的系统

WorkBuddy 没有直接开干，而是先反问了三个问题：优化目标（磁盘 / 开机 / 内存 / 开发缓存）、执行方式（只读报告 / 低风险自动 / 全权自动）、是否涉及个人目录。我选了「开机慢卡顿 + 开发环境缓存堆积」「先出只读诊断报告」「个人目录只盘点不删除」。

这一步很关键：把"只读"和"删除"分开，能避免不可逆误删。

二、诊断：不看进程，看配置

诊断阶段遇到一个限制：沙箱环境下 ps、top、launchctl list 全部返回 operation not permitted，读不出实时进程。

但这反而逼出了一个更可靠的思路——直接核对启动配置与其指向的程序是否还存在。

整个排查方法的完整链路如下：

# 1. 列出所有启动配置
ls -1 ~/Library/LaunchAgents
ls -1 /Library/LaunchAgents
ls -1 /Library/LaunchDaemons

# 2. 读取每个 plist 实际执行的程序路径
/usr/libexec/PlistBuddy -c "Print :ProgramArguments" <plist文件路径>

# 3. 逐一验证目标程序是否还在（关键）
for p in "..."; do [ -e "$p" ] && echo "存在 $p" || echo "已丢失 $p"; done

最后一步是整个诊断的核心。当配置文件还在、程序本体却已消失时，系统每次开机都会尝试拉起它、失败、重试——这就是所谓的僵尸启动项。

三、三个核心发现

下图即当时生成的诊断报告，保留了优化前的全部原始数据：

发现 1：4 个僵尸启动项，全部指向已卸载的软件

这四个软件的 App 早就从 /Applications 里删掉了，但 LaunchDaemon 配置文件还躺在 /Library/LaunchDaemons。它们不会造成崩溃，只是每次开机都白跑一趟，并持续往系统日志里刷错误。

这类残留特别容易被忽略——因为用"启动项管理"工具看，它们名字正常、状态正常，只有去核对文件路径才会暴露。

发现 2：MySQL 开机自启，是开机耗时的头号单项

com.oracle.oss.mysql.mysqld
  → /usr/local/mysql/bin/mysqld --user=_mysql --basedir=/usr/local/mysql ...

mysqld 被注册成了 LaunchDaemon，每次开机必然拉起一个完整的数据库服务。而我只是偶尔本地跑一下测试库，完全不需要它常驻。

发现 3：17GB 的"幽灵"虚拟机

~/Library/Group Containers/4C6364ACXT.com.parallels.desktop.appstore/Shared/Parallels/Windows 11.pvm
  17 GB

Parallels Desktop 主程序已经不在 /Applications 里了，只剩这台 Windows 11 的虚拟磁盘和挂起内存镜像。17GB 静静地躺着，谁也没在用。

顺带一提，磁盘整体余量是 70Gi（约 30%），内存空闲率 88%、swap 只用掉 1MB——内存和磁盘都不是瓶颈。如果只看"卡顿"就跑去删照片、清素材，方向就全错了。

四、执行：分三档，全部可回滚

WorkBuddy 把优化拆成了三档，我按风险从低到高执行。

A 档：砍掉启动项（收益最大）

# 用户级：关闭百度网盘登录自启（无需 root）
mv ~/Library/LaunchAgents/netdisk_service.plist ~/.Trash/

# 系统级：需要 root，逐个禁用后重命名配置文件
sudo launchctl bootout system/com.oracle.oss.mysql.mysqld
sudo launchctl disable system/com.oracle.oss.mysql.mysqld
sudo mv /Library/LaunchDaemons/com.oracle.oss.mysql.mysqld.plist \
        /Library/LaunchDaemons/com.oracle.oss.mysql.mysqld.plist.disabled

要点：只重命名、不删除。把 .plist 改成 .plist.disabled，launchd 会自然忽略它，想还原改回后缀即可。MySQL 的数据库文件一个都没动，需要时手动 mysql.server start 照样能用。

上面是原理。实际操作我没有逐条敲命令，而是把这套逻辑封装成了一个 .command 脚本——双击打开终端、输入一次管理员密码，自动跑完全部 5 项：

每一项都打印了三步结果（停止实例 → 永久禁用 → 重命名配置），最后收尾时主动打印当前目录状态和还原方法——这是刻意设计的，任何一步想反悔都有据可查：

执行结果：成功 5 项、跳过 0 项。/Library/LaunchDaemons 里剩下 3 个正常的苹果/Java 官方项，5 个目标项全部变成 .plist.disabled。

B 档：清理缓存（3.8GB，全部可再生）

清之前先做了一件事——确认这些软件是不是正在运行：

stat -f "%Sm" -t "%Y-%m-%d %H:%M" ~/Library/Caches/JetBrains   # 2026-03-20
stat -f "%Sm" -t "%Y-%m-%d %H:%M" ~/Library/Caches/Firefox     # 2023-08-02

Firefox 缓存最后写入停在 2023 年，JetBrains 停在半年前，都没有活跃进程，可以安全清理。这个"看 mtime 判断是否在跑"的技巧，在拿不到 ps 的时候特别好用。

清理结果：

~/Library/Caches   5.5G  →  1.7G

终端实测（清理后立即执行 du -sh ~/Library/Caches）：

两点说明，都是实机操作才会遇到的真实情况：

• 图里那几行 Operation not permitted 是正常的。macOS 对 Safari、HomeKit、CloudKit 等系统缓存做了 TCC 保护，终端默认没有"完全磁盘访问权限"就会报这个错——不影响统计结果，反而说明这些目录动不了也不该动。
• 注意此刻 /Library/LaunchDaemons 仍列着全部 8 项。缓存清理不需要 root、已完成；但 MySQL 和 4 个僵尸启动项是系统级配置，需要管理员权限单独处理——这也是下一步脚本要干的活。

其中 JetBrains 1.6G、Firefox 1.1G、Mozilla 533M、helpd 359M、PyCharm 2019.2 旧版 160M。全部走 mv → ~/.Trash（移入废纸篓），没有用 rm 硬删。

pip / npm / Homebrew 则用各自官方命令清理：

pip3 cache purge
npm cache clean --force
brew cleanup

C 档：需要用户拍板（涉及数据）

17GB 的 Parallels 虚拟机、~/Downloads 9.8GB、~/Documents 6.2GB，这些都含个人数据，我没有动，交给所有者决定。

五、踩坑记录

1. 沙箱下的权限边界

ps / top / launchctl list / sudo 均被拦截。系统级启动项必须靠人工跑一次 sudo 脚本解决——我把这一步固化成了一个 .command 文件，双击即弹出密码框。

2. ~/.Trash 可以写入，但不允许删除

这是个有趣的现象：能 mv 进去，不能 rm 出来。反而帮了忙——所有"删除"都变成了可恢复的移动操作。

3. 别碰正在运行的软件的缓存

判断方法就是上面那个 stat 看 mtime 的技巧。代价极低，收益是避免 IDE 索引损坏。

4. macOS 12 已是这台机器的终点

MacBookPro12,1 最高只支持到 Monterey，且 Monterey 已停止安全更新。启动项优化能明显改善开机速度，但日常流畅度的天花板就是那颗双核 CPU——这一点要如实告诉用户，而不是让"优化"制造不切实际的期待。

六、效果与复盘

优化前后对比：

• 启动项：移除 6 个（4 个僵尸项 + MySQL 开机自启 + 百度网盘登录自启），其余 8 个确认为有效服务后保留；系统级部分实测「成功 5 项、跳过 0 项」，重启后生效
• 缓存：释放 3.8GB
• 全程零数据丢失，所有操作可回滚

最终交付的三件产物，都是可以直接拿去复用的：

其中脚本已把"只重命名不删除"落成默认行为——任何一步想反悔，把 .plist.disabled 改回 .plist 即可。

回头看，真正有价值的不是"清了 3.8GB"，而是僵尸启动项这个发现。它不会报错、不会崩溃，只是日复一日地拖慢每一次开机，而常规清理工具根本发现不了——因为它们只检查"有没有这个启动项"，不检查"这个启动项指向的东西还在不在"。

七、可复用的排查清单

如果你也想给 Mac 做一次体检，按这个顺序来：

# 1. 启动项清单
ls -1 ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons

# 2. 每个启动项指向什么
/usr/libexec/PlistBuddy -c "Print :ProgramArguments" <plist>

# 3. 目标程序还在吗 —— 揪出僵尸项
[ -e "<程序路径>" ] && echo 存在 || echo 已丢失

# 4. 空间占用 Top
du -sh -x ~/Library/* | sort -rh | head -12

# 5. 清缓存前确认软件未在运行
stat -f "%Sm" -t "%Y-%m-%d %H:%M" <缓存目录>

写在最后：这次体验里，WorkBuddy 最让我认可的不是"会自动执行命令"，而是在执行前先把目标拆清楚、把风险分级、把需要人工确认的部分明确交还给我。系统优化的价值不在于删了多少 GB，而在于知道每一 GB 该不该删。