2026/9/20 9:05:41
FEATURED · 精选文章 
1. 从一条磁盘告警说起为什么开发者的Mac总是先爆存储1.1 一个几乎人人都遇到过的场景如果你是一名移动端或跨平台开发者大概率经历过这样的时刻某天早上打开 Mac系统弹出一条冷冰冰的提示——您的启动磁盘几乎已满。点开关于本机里的存储管理一看好家伙系统数据占了 180G应用程序占了 90G剩下的空间连编译一次 Flutter 项目都够呛。我自己的主力机是一台 512G 的 MacBook Pro做 Flutter 和 iOS 开发大概三年。第一次遇到磁盘告警的时候我以为是照片和视频占的空间结果用磁盘分析工具一扫真正的大头根本不是用户文件而是各种开发工具留下的缓存、派生数据、模拟器镜像、旧版本 SDK、构建产物。这些东西单个看起来不大几十兆到几个 G但架不住数量多、版本多、项目多累积起来轻松突破 100G。标题里提到的清理 100G 垃圾文件并不是夸张的营销话术而是很多中高级开发者的真实处境。尤其是同时维护多个 Flutter 项目、装了好几个 Xcode 版本、又喜欢折腾各种终端工具和 AI 编程助手的人磁盘空间被蚕食的速度远超想象。1.2 这篇内容适合谁看这篇分享主要面向三类人。第一类是 Mac 上的 Flutter 或 iOS 开发者正在被磁盘空间困扰想搞清楚空间到底去哪了。第二类是刚开始用 Claude Code、Codex 这类 AI 编程助手的人发现装完之后磁盘占用莫名其妙涨了一大截。第三类是喜欢用终端工具做系统维护、想学一套可复用的清理方法论的人。需要提前说明的是我下面讲的所有操作都基于 macOS 环境涉及的命令行操作请在理解含义之后再执行不要无脑复制粘贴。清理系统文件这件事删对了是释放空间删错了可能要把整个开发环境重装一遍这个代价我踩过不希望你也踩。1.3 核心思路先定位再分类最后才动手很多人清理磁盘的习惯是打开访达看到大文件夹就删这种做法在开发机上极其危险。正确的顺序应该是三步先用工具把空间占用可视化搞清楚每一块空间被什么占了然后按可安全删除需要谨慎处理绝对不能碰三类归档最后才是执行删除并且优先用工具自带的清理命令而不是手动 rm。这个思路贯穿全文。我会先讲怎么定位空间再逐个拆解 Flutter、Xcode、终端工具、AI 编程助手这几大占用源最后给出一套可以定期执行的清理流程。整个过程不需要装什么付费软件系统自带工具加几条命令就够了。2. 定位阶段把看不见的空间占用变成一张清单2.1 系统自带工具够不够用macOS 自带的存储管理系统设置 → 通用 → 存储能给出一个大致分类比如应用程序文档系统数据等。但它的颗粒度太粗系统数据这一项经常显示几十上百 G却不告诉你具体是什么。对于开发者来说这个粒度完全不够用。我一般会用两个层次的工具配合。第一层是图形化的磁盘分析工具用来快速找到大块头第二层是命令行工具用来精确统计某个目录的大小。图形化工具推荐开源的磁盘空间分析器它能以矩形树图的方式展示每个文件夹的占比一眼就能看出哪个目录是罪魁祸首。命令行则用du和find组合适合做精确统计和批量筛选。2.2 用 du 命令快速摸清家底打开终端先看整体情况。下面这条命令会列出用户主目录下每个一级子目录的大小并按从大到小排序du -sh ~/* 2/dev/null | sort -rh | head -20-s表示汇总-h表示人类可读sort -rh按数值倒序排列head -20只看前 20 个。执行完之后你大概率会看到Library、Documents、Downloads这几个目录排在前列。其中~/Library是开发缓存的重灾区值得单独深挖。接着深入 Library 目录du -sh ~/Library/* 2/dev/null | sort -rh | head -20这一步通常能揪出几个大户DeveloperXcode 相关、Caches各种缓存、Application Support应用数据、Containers沙盒应用数据。我最近一次执行时Developer目录占了 62GCaches占了 28G光这两项就接近 90G。2.3 用 find 定位大文件有时候空间是被少数几个超大文件吃掉的比如某个模拟器镜像、某个日志文件。这时候用find更直接find ~ -type f -size 500M 2/dev/null -exec ls -lh {} \; | awk {print $5, $9} | sort -rh | head -30这条命令会找出主目录下所有大于 500M 的文件列出大小和路径。实测下来经常能发现几个 G 的.dmg安装包、几个 G 的模拟器磁盘镜像、还有动辄上 G 的构建缓存文件。这些文件往往是你几个月前下载或生成的早就没用了。注意find遍历整个主目录会比较慢如果只想看某个子目录把~换成具体路径即可。另外2/dev/null是为了屏蔽权限不足的报错不影响结果。2.4 建立一份自己的空间占用清单定位阶段结束后建议你手动整理一份清单格式大概是路径 大小 用途 处理建议。我自己的清单长这样路径典型大小用途处理建议~/Library/Developer/Xcode/DerivedData10-40GXcode 构建派生数据可安全删除会自动重建~/Library/Developer/CoreSimulator/Devices5-30G模拟器设备镜像删除不用的模拟器~/Library/Caches5-30G各类应用缓存分类处理部分可删~/flutter/bin/cache2-10GFlutter SDK 缓存可用 flutter 命令清理~/.pub-cache1-5GDart 包缓存可清理旧版本~/.npm / ~/.yarn1-10G前端包缓存可安全清理~/Library/Application Support/Claude1-5GAI 助手本地数据谨慎处理有了这张表清理的时候心里就有底了。哪些能删、哪些要留、哪些删了会有什么后果一目了然。3. Flutter 开发环境的空间黑洞与清理实操3.1 Flutter 的空间都花在哪了Flutter 看起来是个轻量框架但实际用起来磁盘占用一点不轻。主要占用来自几个地方SDK 本身的bin/cache目录、Dart 包缓存~/.pub-cache、每个项目的build目录、以及 Gradle 和 CocoaPods 的缓存。先说bin/cache。Flutter SDK 会把 Dart SDK、各种平台的引擎产物、预编译的工具都放在这里。随着 Flutter 版本升级旧版本的产物不一定会被自动清理我见过有人的bin/cache涨到 8G 以上。这个目录可以用官方命令清理flutter precache --clean或者更彻底一点直接删掉整个 cache 目录下次运行 flutter 命令时会自动重新下载rm -rf ~/flutter/bin/cache提示删掉 cache 之后第一次运行 flutter 命令会重新下载依赖需要联网耗时几分钟。建议在网络好的时候操作。3.2 pub-cache 的清理策略~/.pub-cache存放的是所有 Flutter/Dart 项目下载过的第三方包。问题是不同项目依赖不同版本的同一个包时这些版本会同时保留时间一长就堆积成山。清理方法有两种温和的和激进的。温和的方式是只清理不再被任何项目引用的包flutter pub cache repair这条命令会重新下载并修复缓存顺带清理掉损坏或多余的版本。激进的方式是直接清空整个缓存flutter pub cache clean清空之后所有项目下次构建时会重新下载依赖。如果你的项目多、依赖复杂重新下载可能要花不少时间但换来的是干净的环境。我一般每隔两三个月做一次彻底清理。3.3 项目 build 目录最容易被忽视的占用每个 Flutter 项目在构建后都会生成build目录里面是编译产物。单个项目的 build 目录可能几百兆到几个 G如果你有十几个项目加起来就是十几个 G。这些产物随时可以重新生成属于最安全的清理对象。手动清理的话逐个项目执行cd /path/to/your/flutter/project flutter clean如果项目很多可以写个循环批量处理find ~/Projects -name pubspec.yaml -maxdepth 3 -exec dirname {} \; | while read dir; do echo Cleaning $dir (cd $dir flutter clean) done这段脚本会找到~/Projects下所有 Flutter 项目并逐个执行 clean。实测下来清理十几个项目能释放 10G 到 20G 不等。3.4 Gradle 和 CocoaPods 缓存做 Android 和 iOS 混合开发的话Gradle 和 CocoaPods 的缓存也是大头。Gradle 缓存在~/.gradle/cachesCocoaPods 缓存在~/Library/Caches/CocoaPods。Gradle 缓存清理rm -rf ~/.gradle/cachesCocoaPods 缓存清理rm -rf ~/Library/Caches/CocoaPods pod cache clean --all这两个目录删掉之后下次构建会重新下载依赖。Gradle 缓存有时候能到 10G 以上尤其是你做过多个不同技术栈的 Android 项目。3.5 一个完整的 Flutter 清理脚本把上面这些串起来我写了一个可以定期执行的清理脚本放在~/scripts/clean_flutter.sh#!/bin/bash echo Flutter 环境清理开始 echo 1. 清理 Flutter SDK 缓存 flutter precache --clean 2/dev/null echo 2. 清理 pub 缓存 flutter pub cache clean -f 2/dev/null echo 3. 清理项目 build 目录 find ~/Projects -name pubspec.yaml -maxdepth 3 -exec dirname {} \; | while read dir; do (cd $dir flutter clean /dev/null 21) done echo 4. 清理 Gradle 缓存 rm -rf ~/.gradle/caches echo 5. 清理 CocoaPods 缓存 rm -rf ~/Library/Caches/CocoaPods echo 清理完成 df -h / | tail -1最后一行会打印磁盘剩余空间方便对比清理效果。我实测跑一次大概能释放 20G 到 40G取决于你多久没清理。4. Xcode 与模拟器Mac 开发者的头号空间杀手4.1 DerivedData 为什么能涨到几十 GXcode 的 DerivedData 目录存放的是构建过程的中间产物、索引、日志等。它的设计初衷是加速后续构建但代价是占用大量空间。每个项目、每个构建配置都会生成独立的派生数据而且 Xcode 不会自动清理旧数据。查看 DerivedData 大小du -sh ~/Library/Developer/Xcode/DerivedData我见过最夸张的情况是 47G。清理方法很简单直接删掉整个目录rm -rf ~/Library/Developer/Xcode/DerivedData/*删掉之后下次打开项目会重新构建索引第一次构建会慢一些之后就恢复正常。这个操作完全安全不会影响项目源码。4.2 模拟器镜像看不见的几个 GiOS 模拟器的每个设备都对应一个磁盘镜像存放在~/Library/Developer/CoreSimulator/Devices。如果你装了很多不同型号、不同系统版本的模拟器这个目录能轻松超过 20G。先看看有哪些模拟器xcrun simctl list devices删除不再使用的模拟器xcrun simctl delete unavailable这条命令会删除所有不可用的模拟器也就是那些对应的运行时已经被卸载、但设备记录还残留的。如果想更彻底可以删除所有模拟器然后重建xcrun simctl delete all注意delete all会删掉所有模拟器设备包括你正在用的。执行后需要重新创建建议先确认一下有没有重要数据。4.3 旧版本 iOS 运行时和 Xcode 归档Xcode 的旧版本运行时存放在~/Library/Developer/CoreSimulator/Profiles/Runtimes每个运行时几个 G。如果你升级过 iOS 版本旧运行时可能还留着。可以在 Xcode 的 Settings → Platforms 里查看和删除。另外Xcode 的归档文件Archives存放在~/Library/Developer/Xcode/Archives每次打包发布都会生成一个。这些归档用于符号化崩溃日志但旧版本的归档通常可以删。查看大小du -sh ~/Library/Developer/Xcode/Archives我一般只保留最近三个月的归档更早的删掉。4.4 Xcode 缓存和日志还有几个容易被忽略的目录~/Library/Developer/Xcode/iOS DeviceSupport存放真机调试时提取的系统符号每个 iOS 版本几个 G~/Library/Developer/Xcode/UserData用户配置和代码片段~/Library/Logs各种日志文件DeviceSupport 目录尤其值得清理旧版本 iOS 的符号文件在你不调试那个版本的真机时完全没用rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/*4.5 Xcode 清理的完整流程把 Xcode 相关的清理整理成一套流程#!/bin/bash echo Xcode 环境清理开始 echo 1. 清理 DerivedData rm -rf ~/Library/Developer/Xcode/DerivedData/* echo 2. 清理不可用的模拟器 xcrun simctl delete unavailable 2/dev/null echo 3. 清理旧的真机符号 rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/* echo 4. 清理旧归档保留最近90天 find ~/Library/Developer/Xcode/Archives -type d -mtime 90 -exec rm -rf {} \; 2/dev/null echo 5. 清理 Xcode 缓存 rm -rf ~/Library/Caches/com.apple.dt.Xcode echo 清理完成 df -h / | tail -1这套流程跑下来通常能释放 30G 到 60G。我自己最近一次执行DerivedData 释放了 28G模拟器释放了 12GDeviceSupport 释放了 8G加起来接近 50G。5. 终端工具与 AI 编程助手的空间占用5.1 终端工具本身不占空间但它们的缓存会标题里提到了终端、Tabby 终端工具这些关键词。终端工具本身安装包不大但用久了会产生不少缓存和历史数据。比如 Tabby 这类现代化终端会保存会话历史、插件、配置备份时间长了也能占几个 G。查看终端相关目录du -sh ~/.config ~/.cache ~/.local 2/dev/null~/.cache是很多命令行工具的缓存目录包括包管理器、构建工具、AI 助手的临时文件。这个目录里的内容大部分可以安全删除程序会在需要时重新生成。5.2 Claude Code 和 Codex 的本地数据Claude Code 和 Codex 这类 AI 编程助手本地会保存会话历史、项目索引、模型缓存等数据。以 Claude 为例数据通常在~/Library/Application Support/Claude和~/.claude目录下。查看占用du -sh ~/.claude ~/Library/Application\ Support/Claude 2/dev/null这些目录里会话历史通常叫history或sessions和日志文件是可以清理的但配置文件不要动。我一般会保留配置只清理超过一定时间的会话记录。Codex 类似数据在~/.codex或~/Library/Application Support/Codex。清理时同样遵循保留配置、清理历史的原则。提示清理 AI 助手的会话历史前确认一下有没有需要保留的对话记录。有些工具支持导出可以先导出再清理。5.3 包管理器缓存npm、yarn、pnpm前端和 Node.js 相关的缓存也是大头。npm 的缓存在~/.npmyarn 在~/.cache/yarnpnpm 在~/.pnpm-store。这些缓存动辄几个 G。清理命令npm cache clean --force yarn cache clean pnpm store prune这三个命令都是官方提供的安全可靠。我实测 npm 缓存清理能释放 3G 到 8G取决于你装过多少包。5.4 Homebrew 的清理用 Homebrew 装软件的话旧版本和下载缓存也会占空间。Homebrew 提供了专门的清理命令brew cleanup -s-s表示同时清理下载缓存。这条命令会删除旧版本的软件包和缓存的安装包。我一般每个月跑一次能释放 2G 到 5G。还可以看看哪些包占用大brew list --formula | xargs -n1 -P8 -I {} sh -c brew list --formula {} | xargs -I {} du -sh {} 2/dev/null | sort -rh | head -205.5 Docker 镜像和容器如果你用 Docker那它可能是比 Xcode 还大的空间黑洞。Docker 的镜像、容器、卷都存在~/Library/Containers/com.docker.docker里用久了轻松几十 G。查看占用docker system df清理未使用的资源docker system prune -a --volumes这条命令会删除所有未使用的镜像、容器、网络和卷。执行前确认一下没有正在运行的重要容器。6. 常见问题与排查技巧实录6.1 清理后空间没释放多少怎么办有时候你删了一堆文件但df -h显示剩余空间没怎么变。这通常有几个原因。一是 macOS 的可清除空间机制系统会把一些文件标记为可清除但不立即释放重启后才会真正回收。二是某些文件被进程占用删除后空间要等进程退出才释放。三是 Time Machine 的本地快照占用了空间。查看本地快照tmutil listlocalsnapshots /删除快照tmutil deletelocalsnapshots /6.2 哪些目录绝对不能删清理磁盘最怕的就是删错东西。下面这些目录除非你非常清楚后果否则不要碰~/Library/Keychains钥匙串删了所有密码都没了~/Library/Preferences应用配置删了所有软件要重新设置~/Library/Application Support下的配置文件非缓存部分~/.sshSSH 密钥删了所有服务器都连不上~/.gitconfigGit 全局配置判断一个目录能不能删有个简单原则如果它是缓存派生构建产物日志基本可以删如果它是配置密钥数据库源码不要删。6.3 常见问题速查表问题现象可能原因解决方法删除后空间未释放系统可清除空间/进程占用重启或删除本地快照flutter clean 报错项目依赖损坏先 flutter pub get 再 clean模拟器删不掉模拟器正在运行先关闭模拟器再删Docker 清理后仍占空间卷未清理加 --volumes 参数清理后构建变慢缓存被清空正常现象首次构建会慢找不到大文件权限不足用 sudo 或检查目录权限6.4 我的独家避坑经验第一条经验清理前先备份重要配置。我习惯把~/.ssh、~/.gitconfig、各种工具的配置文件同步到云盘或另一台机器。这样即使误删也能快速恢复。第二条经验不要一次性删太多。我一般分批次清理每批清理完观察一两天确认开发环境正常再继续。曾经有一次我图省事把~/Library/Caches整个删了结果某个工具的授权信息丢了重新配置花了半小时。第三条经验用脚本记录清理历史。我在清理脚本里加了一行把每次清理的时间和释放的空间追加到一个日志文件。这样过一段时间回头看就知道哪些目录增长最快可以针对性优化。第四条经验定期清理比一次性大扫除更有效。我现在设置了一个每月提醒跑一次清理脚本每次释放十几 G磁盘再也没告警过。比起攒到 100G 再痛苦地清理这种细水长流的方式轻松得多。6.5 一个可以定期执行的综合清理脚本把前面所有内容整合成一个综合脚本放在~/scripts/clean_all.sh#!/bin/bash LOG~/scripts/clean_history.log echo 清理开始 $(date) | tee -a $LOG BEFORE$(df -k / | tail -1 | awk {print $4}) # Flutter flutter precache --clean 2/dev/null flutter pub cache clean -f 2/dev/null find ~/Projects -name pubspec.yaml -maxdepth 3 -exec dirname {} \; | while read dir; do (cd $dir flutter clean /dev/null 21) done # Xcode rm -rf ~/Library/Developer/Xcode/DerivedData/* xcrun simctl delete unavailable 2/dev/null rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/* find ~/Library/Developer/Xcode/Archives -type d -mtime 90 -exec rm -rf {} \; 2/dev/null # 包管理器 npm cache clean --force 2/dev/null yarn cache clean 2/dev/null brew cleanup -s 2/dev/null # Docker docker system prune -a --volumes -f 2/dev/null # 缓存 rm -rf ~/.gradle/caches rm -rf ~/Library/Caches/CocoaPods AFTER$(df -k / | tail -1 | awk {print $4}) FREED$(( (AFTER - BEFORE) / 1024 / 1024 )) echo 本次释放: ${FREED}G | tee -a $LOG df -h / | tail -1 | tee -a $LOG这个脚本我用了大半年每次跑完释放 15G 到 50G 不等。日志文件能帮你追踪长期趋势看看哪个目录是持续增长的。7. 让清理变成习惯而不是救火7.1 设置自动提醒手动记着清理很容易忘。我的做法是用 macOS 自带的日历设置每月重复提醒标题就叫跑清理脚本。提醒触发时打开终端执行bash ~/scripts/clean_all.sh全程不到五分钟。如果你喜欢更自动化的方式可以用launchd配置定时任务。在~/Library/LaunchAgents下创建一个 plist 文件配置每月执行一次脚本。不过我不太推荐完全自动化因为清理过程中偶尔会有需要确认的交互无人值守可能出问题。半自动的方式最稳妥。7.2 监控磁盘趋势光清理不够还要知道空间是怎么涨起来的。我习惯每周看一眼磁盘占用df -h / du -sh ~/Library/Developer ~/Library/Caches ~/.pub-cache 2/dev/null如果发现某个目录一周涨了好几个 G就说明有异常可能是某个工具在疯狂写日志或者某个项目在反复生成构建产物。早发现早处理比攒到磁盘满了再救火强得多。7.3 从源头减少空间占用清理是治标减少产生才是治本。几个从源头控制的做法一是定期卸载不用的开发工具和 SDK比如旧版本的 Xcode、不再维护的模拟器运行时二是项目做完及时归档把不活跃的项目从主目录移走三是给构建产物设置定期清理比如用 CI 的缓存策略控制。还有一个容易被忽视的点下载目录。开发过程中下载的安装包、SDK、镜像文件用完就该删。我见过有人的 Downloads 目录堆了 30G 的安装包全是几个月前下载的。7.4 最后的个人体会清理磁盘这件事本质上是对自己开发环境的一次梳理。每次清理的时候我都会顺便看看哪些工具很久没用了、哪些项目已经结束了、哪些配置可以简化。这个过程带来的不只是空间释放还有对工作环境的重新掌控感。我踩过最大的坑是早期不懂事看到大目录就删结果把 Xcode 的配置删了重新配置开发环境花了一整天。从那以后我就养成了先查用途、再决定删不删的习惯。现在这套流程跑下来512G 的机器常年保持 100G 以上的可用空间再也没被磁盘告警打断过工作。如果你也想试试建议先从定位开始用du命令摸清自己的空间分布然后挑最安全的 DerivedData 和 build 目录练手。等熟悉了再逐步处理其他目录。清理这件事稳比快重要。
Mac开发者磁盘清理实战：Flutter与Xcode环境释放100G空间
1. 从一条磁盘告警说起为什么开发者的Mac总是先爆存储1.1 一个几乎人人都遇到过的场景如果你是一名移动端或跨平台开发者大概率经历过这样的时刻某天早上打开 Mac系统弹出一条冷冰冰的提示——您的启动磁盘几乎已满。点开关于本机里的存储管理一看好家伙系统数据占了 180G应用程序占了 90G剩下的空间连编译一次 Flutter 项目都够呛。我自己的主力机是一台 512G 的 MacBook Pro做 Flutter 和 iOS 开发大概三年。第一次遇到磁盘告警的时候我以为是照片和视频占的空间结果用磁盘分析工具一扫真正的大头根本不是用户文件而是各种开发工具留下的缓存、派生数据、模拟器镜像、旧版本 SDK、构建产物。这些东西单个看起来不大几十兆到几个 G但架不住数量多、版本多、项目多累积起来轻松突破 100G。标题里提到的清理 100G 垃圾文件并不是夸张的营销话术而是很多中高级开发者的真实处境。尤其是同时维护多个 Flutter 项目、装了好几个 Xcode 版本、又喜欢折腾各种终端工具和 AI 编程助手的人磁盘空间被蚕食的速度远超想象。1.2 这篇内容适合谁看这篇分享主要面向三类人。第一类是 Mac 上的 Flutter 或 iOS 开发者正在被磁盘空间困扰想搞清楚空间到底去哪了。第二类是刚开始用 Claude Code、Codex 这类 AI 编程助手的人发现装完之后磁盘占用莫名其妙涨了一大截。第三类是喜欢用终端工具做系统维护、想学一套可复用的清理方法论的人。需要提前说明的是我下面讲的所有操作都基于 macOS 环境涉及的命令行操作请在理解含义之后再执行不要无脑复制粘贴。清理系统文件这件事删对了是释放空间删错了可能要把整个开发环境重装一遍这个代价我踩过不希望你也踩。1.3 核心思路先定位再分类最后才动手很多人清理磁盘的习惯是打开访达看到大文件夹就删这种做法在开发机上极其危险。正确的顺序应该是三步先用工具把空间占用可视化搞清楚每一块空间被什么占了然后按可安全删除需要谨慎处理绝对不能碰三类归档最后才是执行删除并且优先用工具自带的清理命令而不是手动 rm。这个思路贯穿全文。我会先讲怎么定位空间再逐个拆解 Flutter、Xcode、终端工具、AI 编程助手这几大占用源最后给出一套可以定期执行的清理流程。整个过程不需要装什么付费软件系统自带工具加几条命令就够了。2. 定位阶段把看不见的空间占用变成一张清单2.1 系统自带工具够不够用macOS 自带的存储管理系统设置 → 通用 → 存储能给出一个大致分类比如应用程序文档系统数据等。但它的颗粒度太粗系统数据这一项经常显示几十上百 G却不告诉你具体是什么。对于开发者来说这个粒度完全不够用。我一般会用两个层次的工具配合。第一层是图形化的磁盘分析工具用来快速找到大块头第二层是命令行工具用来精确统计某个目录的大小。图形化工具推荐开源的磁盘空间分析器它能以矩形树图的方式展示每个文件夹的占比一眼就能看出哪个目录是罪魁祸首。命令行则用du和find组合适合做精确统计和批量筛选。2.2 用 du 命令快速摸清家底打开终端先看整体情况。下面这条命令会列出用户主目录下每个一级子目录的大小并按从大到小排序du -sh ~/* 2/dev/null | sort -rh | head -20-s表示汇总-h表示人类可读sort -rh按数值倒序排列head -20只看前 20 个。执行完之后你大概率会看到Library、Documents、Downloads这几个目录排在前列。其中~/Library是开发缓存的重灾区值得单独深挖。接着深入 Library 目录du -sh ~/Library/* 2/dev/null | sort -rh | head -20这一步通常能揪出几个大户DeveloperXcode 相关、Caches各种缓存、Application Support应用数据、Containers沙盒应用数据。我最近一次执行时Developer目录占了 62GCaches占了 28G光这两项就接近 90G。2.3 用 find 定位大文件有时候空间是被少数几个超大文件吃掉的比如某个模拟器镜像、某个日志文件。这时候用find更直接find ~ -type f -size 500M 2/dev/null -exec ls -lh {} \; | awk {print $5, $9} | sort -rh | head -30这条命令会找出主目录下所有大于 500M 的文件列出大小和路径。实测下来经常能发现几个 G 的.dmg安装包、几个 G 的模拟器磁盘镜像、还有动辄上 G 的构建缓存文件。这些文件往往是你几个月前下载或生成的早就没用了。注意find遍历整个主目录会比较慢如果只想看某个子目录把~换成具体路径即可。另外2/dev/null是为了屏蔽权限不足的报错不影响结果。2.4 建立一份自己的空间占用清单定位阶段结束后建议你手动整理一份清单格式大概是路径 大小 用途 处理建议。我自己的清单长这样路径典型大小用途处理建议~/Library/Developer/Xcode/DerivedData10-40GXcode 构建派生数据可安全删除会自动重建~/Library/Developer/CoreSimulator/Devices5-30G模拟器设备镜像删除不用的模拟器~/Library/Caches5-30G各类应用缓存分类处理部分可删~/flutter/bin/cache2-10GFlutter SDK 缓存可用 flutter 命令清理~/.pub-cache1-5GDart 包缓存可清理旧版本~/.npm / ~/.yarn1-10G前端包缓存可安全清理~/Library/Application Support/Claude1-5GAI 助手本地数据谨慎处理有了这张表清理的时候心里就有底了。哪些能删、哪些要留、哪些删了会有什么后果一目了然。3. Flutter 开发环境的空间黑洞与清理实操3.1 Flutter 的空间都花在哪了Flutter 看起来是个轻量框架但实际用起来磁盘占用一点不轻。主要占用来自几个地方SDK 本身的bin/cache目录、Dart 包缓存~/.pub-cache、每个项目的build目录、以及 Gradle 和 CocoaPods 的缓存。先说bin/cache。Flutter SDK 会把 Dart SDK、各种平台的引擎产物、预编译的工具都放在这里。随着 Flutter 版本升级旧版本的产物不一定会被自动清理我见过有人的bin/cache涨到 8G 以上。这个目录可以用官方命令清理flutter precache --clean或者更彻底一点直接删掉整个 cache 目录下次运行 flutter 命令时会自动重新下载rm -rf ~/flutter/bin/cache提示删掉 cache 之后第一次运行 flutter 命令会重新下载依赖需要联网耗时几分钟。建议在网络好的时候操作。3.2 pub-cache 的清理策略~/.pub-cache存放的是所有 Flutter/Dart 项目下载过的第三方包。问题是不同项目依赖不同版本的同一个包时这些版本会同时保留时间一长就堆积成山。清理方法有两种温和的和激进的。温和的方式是只清理不再被任何项目引用的包flutter pub cache repair这条命令会重新下载并修复缓存顺带清理掉损坏或多余的版本。激进的方式是直接清空整个缓存flutter pub cache clean清空之后所有项目下次构建时会重新下载依赖。如果你的项目多、依赖复杂重新下载可能要花不少时间但换来的是干净的环境。我一般每隔两三个月做一次彻底清理。3.3 项目 build 目录最容易被忽视的占用每个 Flutter 项目在构建后都会生成build目录里面是编译产物。单个项目的 build 目录可能几百兆到几个 G如果你有十几个项目加起来就是十几个 G。这些产物随时可以重新生成属于最安全的清理对象。手动清理的话逐个项目执行cd /path/to/your/flutter/project flutter clean如果项目很多可以写个循环批量处理find ~/Projects -name pubspec.yaml -maxdepth 3 -exec dirname {} \; | while read dir; do echo Cleaning $dir (cd $dir flutter clean) done这段脚本会找到~/Projects下所有 Flutter 项目并逐个执行 clean。实测下来清理十几个项目能释放 10G 到 20G 不等。3.4 Gradle 和 CocoaPods 缓存做 Android 和 iOS 混合开发的话Gradle 和 CocoaPods 的缓存也是大头。Gradle 缓存在~/.gradle/cachesCocoaPods 缓存在~/Library/Caches/CocoaPods。Gradle 缓存清理rm -rf ~/.gradle/cachesCocoaPods 缓存清理rm -rf ~/Library/Caches/CocoaPods pod cache clean --all这两个目录删掉之后下次构建会重新下载依赖。Gradle 缓存有时候能到 10G 以上尤其是你做过多个不同技术栈的 Android 项目。3.5 一个完整的 Flutter 清理脚本把上面这些串起来我写了一个可以定期执行的清理脚本放在~/scripts/clean_flutter.sh#!/bin/bash echo Flutter 环境清理开始 echo 1. 清理 Flutter SDK 缓存 flutter precache --clean 2/dev/null echo 2. 清理 pub 缓存 flutter pub cache clean -f 2/dev/null echo 3. 清理项目 build 目录 find ~/Projects -name pubspec.yaml -maxdepth 3 -exec dirname {} \; | while read dir; do (cd $dir flutter clean /dev/null 21) done echo 4. 清理 Gradle 缓存 rm -rf ~/.gradle/caches echo 5. 清理 CocoaPods 缓存 rm -rf ~/Library/Caches/CocoaPods echo 清理完成 df -h / | tail -1最后一行会打印磁盘剩余空间方便对比清理效果。我实测跑一次大概能释放 20G 到 40G取决于你多久没清理。4. Xcode 与模拟器Mac 开发者的头号空间杀手4.1 DerivedData 为什么能涨到几十 GXcode 的 DerivedData 目录存放的是构建过程的中间产物、索引、日志等。它的设计初衷是加速后续构建但代价是占用大量空间。每个项目、每个构建配置都会生成独立的派生数据而且 Xcode 不会自动清理旧数据。查看 DerivedData 大小du -sh ~/Library/Developer/Xcode/DerivedData我见过最夸张的情况是 47G。清理方法很简单直接删掉整个目录rm -rf ~/Library/Developer/Xcode/DerivedData/*删掉之后下次打开项目会重新构建索引第一次构建会慢一些之后就恢复正常。这个操作完全安全不会影响项目源码。4.2 模拟器镜像看不见的几个 GiOS 模拟器的每个设备都对应一个磁盘镜像存放在~/Library/Developer/CoreSimulator/Devices。如果你装了很多不同型号、不同系统版本的模拟器这个目录能轻松超过 20G。先看看有哪些模拟器xcrun simctl list devices删除不再使用的模拟器xcrun simctl delete unavailable这条命令会删除所有不可用的模拟器也就是那些对应的运行时已经被卸载、但设备记录还残留的。如果想更彻底可以删除所有模拟器然后重建xcrun simctl delete all注意delete all会删掉所有模拟器设备包括你正在用的。执行后需要重新创建建议先确认一下有没有重要数据。4.3 旧版本 iOS 运行时和 Xcode 归档Xcode 的旧版本运行时存放在~/Library/Developer/CoreSimulator/Profiles/Runtimes每个运行时几个 G。如果你升级过 iOS 版本旧运行时可能还留着。可以在 Xcode 的 Settings → Platforms 里查看和删除。另外Xcode 的归档文件Archives存放在~/Library/Developer/Xcode/Archives每次打包发布都会生成一个。这些归档用于符号化崩溃日志但旧版本的归档通常可以删。查看大小du -sh ~/Library/Developer/Xcode/Archives我一般只保留最近三个月的归档更早的删掉。4.4 Xcode 缓存和日志还有几个容易被忽略的目录~/Library/Developer/Xcode/iOS DeviceSupport存放真机调试时提取的系统符号每个 iOS 版本几个 G~/Library/Developer/Xcode/UserData用户配置和代码片段~/Library/Logs各种日志文件DeviceSupport 目录尤其值得清理旧版本 iOS 的符号文件在你不调试那个版本的真机时完全没用rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/*4.5 Xcode 清理的完整流程把 Xcode 相关的清理整理成一套流程#!/bin/bash echo Xcode 环境清理开始 echo 1. 清理 DerivedData rm -rf ~/Library/Developer/Xcode/DerivedData/* echo 2. 清理不可用的模拟器 xcrun simctl delete unavailable 2/dev/null echo 3. 清理旧的真机符号 rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/* echo 4. 清理旧归档保留最近90天 find ~/Library/Developer/Xcode/Archives -type d -mtime 90 -exec rm -rf {} \; 2/dev/null echo 5. 清理 Xcode 缓存 rm -rf ~/Library/Caches/com.apple.dt.Xcode echo 清理完成 df -h / | tail -1这套流程跑下来通常能释放 30G 到 60G。我自己最近一次执行DerivedData 释放了 28G模拟器释放了 12GDeviceSupport 释放了 8G加起来接近 50G。5. 终端工具与 AI 编程助手的空间占用5.1 终端工具本身不占空间但它们的缓存会标题里提到了终端、Tabby 终端工具这些关键词。终端工具本身安装包不大但用久了会产生不少缓存和历史数据。比如 Tabby 这类现代化终端会保存会话历史、插件、配置备份时间长了也能占几个 G。查看终端相关目录du -sh ~/.config ~/.cache ~/.local 2/dev/null~/.cache是很多命令行工具的缓存目录包括包管理器、构建工具、AI 助手的临时文件。这个目录里的内容大部分可以安全删除程序会在需要时重新生成。5.2 Claude Code 和 Codex 的本地数据Claude Code 和 Codex 这类 AI 编程助手本地会保存会话历史、项目索引、模型缓存等数据。以 Claude 为例数据通常在~/Library/Application Support/Claude和~/.claude目录下。查看占用du -sh ~/.claude ~/Library/Application\ Support/Claude 2/dev/null这些目录里会话历史通常叫history或sessions和日志文件是可以清理的但配置文件不要动。我一般会保留配置只清理超过一定时间的会话记录。Codex 类似数据在~/.codex或~/Library/Application Support/Codex。清理时同样遵循保留配置、清理历史的原则。提示清理 AI 助手的会话历史前确认一下有没有需要保留的对话记录。有些工具支持导出可以先导出再清理。5.3 包管理器缓存npm、yarn、pnpm前端和 Node.js 相关的缓存也是大头。npm 的缓存在~/.npmyarn 在~/.cache/yarnpnpm 在~/.pnpm-store。这些缓存动辄几个 G。清理命令npm cache clean --force yarn cache clean pnpm store prune这三个命令都是官方提供的安全可靠。我实测 npm 缓存清理能释放 3G 到 8G取决于你装过多少包。5.4 Homebrew 的清理用 Homebrew 装软件的话旧版本和下载缓存也会占空间。Homebrew 提供了专门的清理命令brew cleanup -s-s表示同时清理下载缓存。这条命令会删除旧版本的软件包和缓存的安装包。我一般每个月跑一次能释放 2G 到 5G。还可以看看哪些包占用大brew list --formula | xargs -n1 -P8 -I {} sh -c brew list --formula {} | xargs -I {} du -sh {} 2/dev/null | sort -rh | head -205.5 Docker 镜像和容器如果你用 Docker那它可能是比 Xcode 还大的空间黑洞。Docker 的镜像、容器、卷都存在~/Library/Containers/com.docker.docker里用久了轻松几十 G。查看占用docker system df清理未使用的资源docker system prune -a --volumes这条命令会删除所有未使用的镜像、容器、网络和卷。执行前确认一下没有正在运行的重要容器。6. 常见问题与排查技巧实录6.1 清理后空间没释放多少怎么办有时候你删了一堆文件但df -h显示剩余空间没怎么变。这通常有几个原因。一是 macOS 的可清除空间机制系统会把一些文件标记为可清除但不立即释放重启后才会真正回收。二是某些文件被进程占用删除后空间要等进程退出才释放。三是 Time Machine 的本地快照占用了空间。查看本地快照tmutil listlocalsnapshots /删除快照tmutil deletelocalsnapshots /6.2 哪些目录绝对不能删清理磁盘最怕的就是删错东西。下面这些目录除非你非常清楚后果否则不要碰~/Library/Keychains钥匙串删了所有密码都没了~/Library/Preferences应用配置删了所有软件要重新设置~/Library/Application Support下的配置文件非缓存部分~/.sshSSH 密钥删了所有服务器都连不上~/.gitconfigGit 全局配置判断一个目录能不能删有个简单原则如果它是缓存派生构建产物日志基本可以删如果它是配置密钥数据库源码不要删。6.3 常见问题速查表问题现象可能原因解决方法删除后空间未释放系统可清除空间/进程占用重启或删除本地快照flutter clean 报错项目依赖损坏先 flutter pub get 再 clean模拟器删不掉模拟器正在运行先关闭模拟器再删Docker 清理后仍占空间卷未清理加 --volumes 参数清理后构建变慢缓存被清空正常现象首次构建会慢找不到大文件权限不足用 sudo 或检查目录权限6.4 我的独家避坑经验第一条经验清理前先备份重要配置。我习惯把~/.ssh、~/.gitconfig、各种工具的配置文件同步到云盘或另一台机器。这样即使误删也能快速恢复。第二条经验不要一次性删太多。我一般分批次清理每批清理完观察一两天确认开发环境正常再继续。曾经有一次我图省事把~/Library/Caches整个删了结果某个工具的授权信息丢了重新配置花了半小时。第三条经验用脚本记录清理历史。我在清理脚本里加了一行把每次清理的时间和释放的空间追加到一个日志文件。这样过一段时间回头看就知道哪些目录增长最快可以针对性优化。第四条经验定期清理比一次性大扫除更有效。我现在设置了一个每月提醒跑一次清理脚本每次释放十几 G磁盘再也没告警过。比起攒到 100G 再痛苦地清理这种细水长流的方式轻松得多。6.5 一个可以定期执行的综合清理脚本把前面所有内容整合成一个综合脚本放在~/scripts/clean_all.sh#!/bin/bash LOG~/scripts/clean_history.log echo 清理开始 $(date) | tee -a $LOG BEFORE$(df -k / | tail -1 | awk {print $4}) # Flutter flutter precache --clean 2/dev/null flutter pub cache clean -f 2/dev/null find ~/Projects -name pubspec.yaml -maxdepth 3 -exec dirname {} \; | while read dir; do (cd $dir flutter clean /dev/null 21) done # Xcode rm -rf ~/Library/Developer/Xcode/DerivedData/* xcrun simctl delete unavailable 2/dev/null rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/* find ~/Library/Developer/Xcode/Archives -type d -mtime 90 -exec rm -rf {} \; 2/dev/null # 包管理器 npm cache clean --force 2/dev/null yarn cache clean 2/dev/null brew cleanup -s 2/dev/null # Docker docker system prune -a --volumes -f 2/dev/null # 缓存 rm -rf ~/.gradle/caches rm -rf ~/Library/Caches/CocoaPods AFTER$(df -k / | tail -1 | awk {print $4}) FREED$(( (AFTER - BEFORE) / 1024 / 1024 )) echo 本次释放: ${FREED}G | tee -a $LOG df -h / | tail -1 | tee -a $LOG这个脚本我用了大半年每次跑完释放 15G 到 50G 不等。日志文件能帮你追踪长期趋势看看哪个目录是持续增长的。7. 让清理变成习惯而不是救火7.1 设置自动提醒手动记着清理很容易忘。我的做法是用 macOS 自带的日历设置每月重复提醒标题就叫跑清理脚本。提醒触发时打开终端执行bash ~/scripts/clean_all.sh全程不到五分钟。如果你喜欢更自动化的方式可以用launchd配置定时任务。在~/Library/LaunchAgents下创建一个 plist 文件配置每月执行一次脚本。不过我不太推荐完全自动化因为清理过程中偶尔会有需要确认的交互无人值守可能出问题。半自动的方式最稳妥。7.2 监控磁盘趋势光清理不够还要知道空间是怎么涨起来的。我习惯每周看一眼磁盘占用df -h / du -sh ~/Library/Developer ~/Library/Caches ~/.pub-cache 2/dev/null如果发现某个目录一周涨了好几个 G就说明有异常可能是某个工具在疯狂写日志或者某个项目在反复生成构建产物。早发现早处理比攒到磁盘满了再救火强得多。7.3 从源头减少空间占用清理是治标减少产生才是治本。几个从源头控制的做法一是定期卸载不用的开发工具和 SDK比如旧版本的 Xcode、不再维护的模拟器运行时二是项目做完及时归档把不活跃的项目从主目录移走三是给构建产物设置定期清理比如用 CI 的缓存策略控制。还有一个容易被忽视的点下载目录。开发过程中下载的安装包、SDK、镜像文件用完就该删。我见过有人的 Downloads 目录堆了 30G 的安装包全是几个月前下载的。7.4 最后的个人体会清理磁盘这件事本质上是对自己开发环境的一次梳理。每次清理的时候我都会顺便看看哪些工具很久没用了、哪些项目已经结束了、哪些配置可以简化。这个过程带来的不只是空间释放还有对工作环境的重新掌控感。我踩过最大的坑是早期不懂事看到大目录就删结果把 Xcode 的配置删了重新配置开发环境花了一整天。从那以后我就养成了先查用途、再决定删不删的习惯。现在这套流程跑下来512G 的机器常年保持 100G 以上的可用空间再也没被磁盘告警打断过工作。如果你也想试试建议先从定位开始用du命令摸清自己的空间分布然后挑最安全的 DerivedData 和 build 目录练手。等熟悉了再逐步处理其他目录。清理这件事稳比快重要。 
