从仅剩 6 GB 到狂腾 70 GB：我的 256G Mac mini 深度清理与内存排查实战实测将 256GB Mac

从仅剩 6 GB 到狂腾 70 GB：我的 256G Mac mini 深度清理与内存排查实战

导语：用 256 GB 版（实际容器容量约 245 GB）Mac mini 做主力开发机的朋友，大概都经历过被「您的磁盘空间几乎已满」支配的恐惧。今天花了一个下午，在不破坏任何开发环境和常用配置的前提下，把可用空间从 6.4 GB 一路拉升到了 76.0 GB（净释放近 70 GB）。本文完整复盘这次排查出的各路隐形空间刺客、内存聚合诊断脚本以及三个极易踩坑的 macOS 底层机制。

一、起因：从 525 MB 的树莓派缓存与内存体检说起

起初我只是想看看本地的树莓派烧录工具 Raspberry Pi Imager.app 占了多少空间。用 du -sh 一查发现：

/Applications/Raspberry Pi Imager.app 本体只有 135 MB；
但在 ~/Library/Caches/Raspberry Pi/Raspberry Pi Imager/lastdownload.cache 里，静静躺着上次烧录系统时缓存的镜像文件，占了 525 MB。

清掉这个镜像缓存后，我顺手执行 df -h / 看了一眼磁盘和内存状况，结果发现了电脑近期偶发卡顿的真正元凶：

硬盘可用空间仅剩 6.0 GiB（约 6.4 GB），使用率逼近极限。
16 GB 物理内存处于高压缩与高 Swap 交换状态：因为 Chrome、Cursor、WPS、ChatGPT 等都是多进程架构（包含大量 Renderer / GPU / Helper 子进程），直接看 top 很难看出单个 App 的真实总占用。于是我用一段 awk 脚本按应用合并统计了所有子进程的物理内存（RSS）：

ps -axo rss,comm | awk '
  NR>1 {
    rss=$1; $1=""; cmd=substr($0,2);
    if (match(cmd, /\/Applications\/[^\/]+\.app/)) {
      app=substr(cmd, RSTART+14, RLENGTH-14)
    } else if (cmd ~ /mds_stores|mds/) {
      app="Spotlight (mds_stores)"
    } else {
      app=cmd
    }
    sum[app]+=rss; count[app]++
  }
  END {
    for (a in sum) printf "%8.1f MB  (%2d procs)  %s\n", sum[a]/1024, count[a], a
  }
' | sort -nr | head -n 10

跑出来的结果一目了然：

Google Chrome（32 个进程）：3,522.7 MB (3.44 GB)
WPS Office（12 个进程，含 wpscloudsvr 云服务与内置 CEF 浏览器）：1,338.9 MB (1.31 GB)
ChatGPT 桌面端（36 个进程）：1,165.3 MB (1.14 GB)
Cursor（15 个进程）：944.6 MB
Antigravity（8 个进程）：898.7 MB
Typeless（9 个进程）：428.5 MB

由于多个 Electron / Chromium 内核应用同时常驻，macOS 将 5.6 GB 内存进行了硬件压缩（Compressed），并划分了 3.31 GB 的磁盘交换区（Swap）。当 Swap 需要频繁读写硬盘，而硬盘又只剩 6 GB 空间时，SSD 的写放大和空间碎片就会直接拖慢整机响应。

要让 Mac mini 彻底满血复活，必须先把硬盘空间腾出来。

二、第一刀：揪出「自动更新残留」与「卸载幽灵」（释放 ~16 GB）

平时我们觉得 ~/Library/Caches 和 ~/Library/Application Support 里都是些几十 MB 的小缓存，但用 du -sh ~/Library/Caches/* | sort -hr 排序后，结果让人大跌眼镜：

1. 自动更新器（Sparkle / ShipIt / GoogleUpdater）的「囤积癖」

现在的桌面软件几乎都内置了静默更新机制，但很多更新器在下载完新版安装包并替换完 App 后，根本不会删除旧的安装包缓存：

Codex 更新缓存与日志：
- ~/Library/Caches/com.openai.codex/org.sparkle-project.Sparkle 居然积压了 4.8 GB 的历史更新包！
- 加上 ~/.cache/codex-runtimes（1.6 GB）、~/Library/Logs/com.openai.codex（664 MB）和 ~/Library/Caches/Codex（414 MB），单这一项就吃掉了 7.5 GB。
Electron 应用的 .ShipIt 残留：
- Cursor（com.todesktop.*.ShipIt，970 MB）、Typeless（now.typeless.desktop.ShipIt + typeless-updater，914 MB）、Anysphere（346 MB）、淘宝桌面版（139 MB）等留在 Caches 下的临时升级包，合计占了 2.4 GB。
Chrome 更新包缓存：
- ~/Library/Application Support/Google/GoogleUpdater/crx_cache 占了 756 MB。

2. 已卸载软件留下的「幽灵数据」

很多时候我们卸载 Mac 软件只是把 /Applications 里的图标拖进了废纸篓，殊不知它们在系统深处留下了庞大的家当：

微信开发者工具（早已卸载）：在 ~/Library/Caches 留了 550 MB，在 ~/Library/Application Support 留了 982 MB，合计 1.53 GB。
Video Subtitle Master（字幕工具）：应用本体才 366 MB，但在 ~/Library/Application Support/video-subtitle-master 下存了 2.7 GB 的语音识别模型文件，主目录下还有 ~/.33TaiCi（53 MB）。
Windsurf / Codeium / Trae / Dia / Edge（均已卸载）：散落在 ~/.codeium（469M）、~/.windsurf（117M）、~/.trae（173M）以及 Application Support 里的残留合计超过 1.6 GB。

同时，我还顺手彻底卸载了几个平时几乎不用的桌面软件（淘宝桌面版 1.25 GB、Xmind 593 MB、Inkscape 651 MB、阿里云盘 482 MB、Claude 桌面端 491 MB、爱思助手 393 MB、LocalSend 80 MB），连根拔起了它们的 Application Support 和偏好设置。

三、第二刀：向 Xcode 与 iOS 模拟器「吞金兽」开刀（释放 ~30 GB）

如果你电脑上装了 Xcode，哪怕平时只是偶尔跑一下 React Native 或 iOS 项目，~/Library/Developer 和 /Library/Developer 也绝对是硬盘的头号杀手：

清理项	路径 / 清理命令	释放空间	说明
iOS 真机调试符号	`~/Library/Developer/Xcode/iOS DeviceSupport`	11.0 GB	存着 `iOS 26.6` 和 `iOS 26.5.1` 两套符号表（各 5.7 GB）。删掉完全安全，下次插线调试真机时会自动按需生成
自动化测试克隆设备	`~/Library/Developer/XCTestDevices`	9.8 GB	跑 XCTest 时自动克隆的临时模拟器实例，直接清空
模拟器设备沙盒数据	`~/Library/Developer/CoreSimulator/Devices`	9.5 GB	11 台虚拟 iPhone/iPad 的沙盒数据，通过 `xcrun simctl erase all` 及清理设备目录释放
旧版 iOS 模拟器镜像	`xcrun simctl runtime delete <UUID>`	8.2 GB	本机同时装了 `iOS 26.5` 和旧版 `iOS 18.6` 两套完整系统镜像（共 16.1 GB），删掉旧版 `18.6` 立省一半
Xcode 编译衍生数据	`~/Library/Developer/Xcode/DerivedData` + `Archives`	1.5 GB	项目编译中间缓存，随时可删

常用模拟器清理命令速查：

# 查看已安装的模拟器系统镜像及大小
xcrun simctl runtime list -v

# 删除不需要的旧版模拟器镜像
xcrun simctl runtime delete <Runtime-UUID>

# 清理不可用的模拟器并重置所有模拟器数据
xcrun simctl delete unavailable
xcrun simctl erase all

四、第三刀：前端、Rust 与包管理器的「隐形仓库」（释放 ~22 GB）

作为开发者，各种语言的包管理器缓存如果不定期打理，膨胀速度惊人：

1. npm 清理的盲区（4.8 GB）

平时清理 npm 缓存，大家都会跑 npm cache clean --force。我跑完之后释放了 3.9 GB，但发现 ~/.npm 居然还剩 930 MB！点进去一看，原来 npm cache clean 只会清理 _cacache，默认不会清理 ~/.npm/_npx（909 MB）——每次你用 npx xxx 临时执行一个命令，它都会在 _npx 下偷偷装一套独立的 node_modules。手动执行 rm -rf ~/.npm/_npx ~/.npm/_prebuilds 后，~/.npm 才真正归零。

2. pnpm、Yarn 与 Playwright（7.4 GB）

pnpm 缓存与 Store：清理 ~/Library/Caches/pnpm（1.4 GB）与 ~/Library/pnpm/store（3.9 GB），共释放 5.3 GB（仅保留 ~/Library/pnpm/global 下全局安装的 CLI 工具）。
Yarn Berry 缓存：清理 ~/.yarn/berry 全局缓存，释放 652 MB。
Playwright 浏览器内核：~/Library/Caches/ms-playwright* 下存着自动化测试下载的 Chromium/WebKit 内核，占了 1.4 GB，不跑测试时随时可删，需要时一行 npx playwright install 即可恢复。

3. CocoaPods 的远古包袱（4.6 GB）

~/.cocoapods 占了足足 4.6 GB，里面是数十万个碎小的 podspec JSON 文件（甚至连 du 统计它的大小都要卡上一分钟）。现在的 CocoaPods 早已默认使用 CDN 按需拉取，直接 rm -rf ~/.cocoapods 删掉这 4.6 GB 的本地 Git 索引库毫无副作用。

4. 藏在 `.worktrees` 深处的 Rust 编译产物（7.1 GB）

扫描工作目录 ~/workplace 时，发现一个项目目录看似只有几十 KB 代码，却占了 5.2 GB。用 ls -la 才发现隐藏目录 .worktrees 下有一个 Tauri 项目的 src-tauri/target 编译目录，单它一个就占了 5.1 GB！配合清理近期不用的 ~/.rustup（1.2 GB）和 ~/.cargo/registry（748 MB），一下子又腾出 7.1 GB。

避坑提醒：如果彻底删除了 ~/.cargo，记得检查 ~/.zshenv（或 ~/.zshrc / ~/.bash_profile），把里面的 . "$HOME/.cargo/env" 改为带存在性判断的写法：
[ -f "$HOME/.cargo/env" ] && . "$HOME/.cargo/env"
否则每次打开新终端都会报错 no such file or directory: ~/.cargo/env。

5. VS Code 与 Cursor 的插件安装包备份（1.0 GB）

在 ~/Library/Application Support/Code/CachedExtensionVSIXs（333 MB）和 Cursor/CachedData（382 MB）+ logs（103 MB）中，存着大量插件安装完后留下的 .vsix 压缩包备份和旧版 V8 字节码缓存，删掉完全不影响已安装的插件和配置。

五、三个最容易踩的 macOS「彩蛋级」大坑

在这次清理过程中，我还遇到了三个非常有代表性的 macOS 机制问题：

坑 1：`Caches` 里莫名其妙多了两个 716 MB 的 `SwiftUI.Drag` 目录

在扫描 ~/Library/Caches 时，发现了两个名字很奇怪的目录：

com.apple.SwiftUI.Drag-4CE3292B-AC99-47A4-AE20-F1749D2BA33F（716 MB）
com.apple.SwiftUI.Drag-A4F7F265-D548-4F91-BADC-085A7C295EC8（716 MB）

进目录 ls 一看，里面居然是两份完整的 Gemini.app 副本！原来在 macOS 上，当你从使用 SwiftUI 编写的窗口中用鼠标拖拽（Drag & Drop）文件或应用时，SwiftUI 框架会先在 Caches/com.apple.SwiftUI.Drag-<UUID> 下生成一份完整拷贝。如果拖拽中途取消或未触发回收，这个几百 MB 的副本就会永远留在缓存里。删掉这两个目录，白捡 1.43 GB。

坑 2：命令行 `rm -rf` 删不掉的缓存包（`Permission denied`）

在清理 ~/Library/Caches/dotslash（1.1 GB）和 /Applications/i4tools.app 时，直接在终端执行 rm -rf 会刷屏报错 Permission denied。原因有两个：

dotslash 会把解压出来的二进制目录设为只读（dr-xr-xr-x 无写权限）；
macOS 的 App Management（应用管理）TCC 权限 会阻止未授权终端直接拆解删除带有 _CodeSignature 签名的 .app Bundle 内部结构。

优雅解法：不需要去系统设置里折腾权限，直接通过 osascript 调用 Finder 接口将其移入废纸篓并清空，2 秒搞定：

osascript -e 'tell application "Finder" to delete POSIX file "/Users/你的用户名/Library/Caches/dotslash"'
osascript -e 'tell application "Finder" to empty trash'

坑 3：为什么删了 20 多 GB 文件，可用空间反而从 53 GiB 掉到了 45 GiB？

这是整个清理过程中最戏剧性的一幕：当我删完 iOS DeviceSupport（11 GB）、.cocoapods（4.6 GB）和模拟器数据（9.5 GB）后，运行 df -h / 一看，可用空间非但没涨，反而从 53 GiB 跌到了 45 GiB！

排查 tmutil listlocalsnapshots / 后立刻破案：

Snapshots for disk /:
com.apple.TimeMachine.2026-11-07-140229.local

原来 macOS 在下午 14:02 自动创建了一个 APFS 本地时间机器快照（Local Snapshot）！由于 APFS 的写时复制（Copy-on-Write）特性，我在 14:02 之后删除的所有文件块，全都被这个本地快照给「锁」住了，没有真正释放回空闲池。

只需要运行下面这行无需 sudo 的命令，让系统立即收缩并清理本地快照：

tmutil thinlocalsnapshots / 100000000000 4

命令执行完的一瞬间，可用空间直接从 45 GiB 暴涨到了 71 GiB（76.0 GB），整整 26 GiB 被快照锁住的空间瞬间释放！

六、最终战果总览

经过这一轮大扫除，这台 256 GB 的 Mac mini 最终成绩单如下：

指标	清理前	清理后	变化
Finder 可用空间（十进制）	6.4 GB	76.0 GB	+69.6 GB
终端 `df -h` 可用空间（二进制）	6.0 GiB	71 GiB	+65 GiB
磁盘已用比例	97%+（红色告警）	15%（容器总空闲超 31%）	恢复极佳状态

如果你也在用 256 GB 或 512 GB 的 Mac 做开发，当磁盘告急时，不妨按这个顺序排查一遍：

应用更新包残留（Sparkle / .ShipIt / GoogleUpdater）
已卸载软件的 Application Support 与主目录隐藏文件夹
Xcode 真机符号（iOS DeviceSupport）与测试模拟器（XCTestDevices / 旧 Runtime）
包管理器隐藏目录（~/.npm/_npx / pnpm store / ~/.cocoapods / ~/.yarn/berry）
项目 .worktrees 下的 target / node_modules
最后用 tmutil thinlocalsnapshots / 100000000000 4 释放 APFS 本地快照

从仅剩 6 GB 到狂腾 70 GB：我的 256G Mac mini 深度清理与内存排查实战