macOS 磁盘空间优化实战：从“系统数据爆炸”到可持续治理
type
status
date
slug
summary
tags
category
icon
password
wechat_gate
在 macOS 上，磁盘长期接近满载（例如 90%+）会直接导致系统体验恶化：应用启动变慢、切换卡顿、索引和缓存回收效率下降，甚至出现 UI 假死。很多用户会在“存储空间”面板看到
系统数据 异常偏大，但很难定位到底是谁占了空间。本文基于一次真实排查过程，给出一套可复用的技术化排查与优化方案，重点解决：
- 为什么“系统数据”看起来巨大
- 如何快速定位真实大头目录
- 如何按收益优先级安全释放空间
- 如何建立长期治理，避免反复爆盘
一、问题背景与现场数据
本次机器的关键指标如下：
- 数据卷使用率：
/System/Volumes/Data=406Gi / 460Gi，约94%
- 时间机器本地快照：无（排除该常见原因）
- 用户可见现象：系统卡顿、存储面板中“系统数据”异常偏大
高占用状态下，即使还有十几 GB 可用空间，系统也会因为写放大、缓存压力、swap 行为而明显变慢。
二、排查方法（可复用）
1. 先确认真实占用与挂载卷
2. 排除 Time Machine 本地快照
3. 定位用户目录大头
4. 深入到二级目录，找“可清理且高收益”的目标
5. 校验系统级开发缓存与临时目录
三、关键发现（本次实测）
1. 用户态开发目录是最大来源
~/Library/Developer：104G
- 其中
~/Library/Developer/CoreSimulator：65G
- 其中
~/Library/Developer/Xcode/iOS DeviceSupport：36G
2. 系统级开发缓存也在放大“系统数据”
/Library/Developer/CoreSimulator/Caches：14G
3. 用户缓存与应用支持目录次级放大
~/Library/Caches：23G- JetBrains 缓存约
13G - Yarn 缓存约
4.1G
~/Library/Application Support：44G- Claude 相关约
10G - LarkShell 约
8G - Microsoft Edge Profile 约
7G
4. 结论
“系统数据大”并不等于 macOS 本体不可控，核心通常是：
- 开发工具残留（模拟器、DeviceSupport、IDE 缓存）
- 应用缓存和运行时资产
- 被 UI 归类到“系统数据”的可管理目录
四、优化策略：按收益优先级执行
优先级 P0：先把系统从高压状态拉回安全区
目标：至少释放
60-100G，把数据卷使用率降到 80% 左右。P0-1 清理 Xcode 与模拟器（最高收益）
如不需要保留所有模拟器内 App 数据：
预期释放：
50-90GP0-2 清理用户缓存（低风险高收益）
预期释放：
15-25GP0-3 清理应用支持目录中的大缓存
重点关注：
~/Library/Application Support/Claude
~/Library/Application Support/LarkShell
~/Library/Application Support/Microsoft Edge
~/Library/Application Support/JetBrains
建议优先删除缓存、更新包、临时文件，不要先删主配置与业务数据。
预期释放：
10-20G优先级 P1：执行后收敛
P1-1 重启一次系统
重启可触发部分临时文件与 swap 回收，也让存储统计重新计算。
P1-2 复查指标
五、风险控制与回滚思路
- 删除前先确认目录性质：缓存 vs 数据
- 对不确定目录先备份再删
- 避免一次性“全删”应用 profile（浏览器配置、会话、插件可能丢失）
- 使用
sudo rm -rf前务必二次确认路径
六、长期治理：避免再次爆盘
1. 建议阈值
- 使用率 > 80%：开始清理
- 使用率 > 90%：进入应急清理
2. 开发机周期清理（每 2~4 周）
- 清理
CoreSimulator无效设备
- 清理 Xcode DeviceSupport 历史版本
- 清理 IDE 与包管理器缓存
3. 建立自动巡检脚本（可选）
当目录超阈值时，提醒人工确认清理。
七、总结
本次案例说明：
- “系统数据异常大”多数可解释、可治理
- 优先抓开发目录与缓存，收益远高于盲删应用
- 一次应急释放空间后，必须配合周期化治理，否则很快反弹
如果你的 Mac 也长期卡顿，先做分层定位，再按收益优先级执行清理，通常都能在 30 分钟内恢复明显流畅度。
养成定期清理电脑空间的好习惯！