Mac 的 ~/Library/Caches 是什么，哪些可以删除

存储空间发布于 更新于 约 5 分钟

真正的缓存可以重新生成，但名字里带 Cache 的目录并不自动等于能删，因为应用有时会把离线下载、会话状态、索引和未同步内容就近放在缓存旁边。Apple 的 Library 目录说明把缓存定义为可重新生成、应用不应依赖其持续存在的内容。动手前最好先弄清文件属于谁、从哪里重建，以及删掉之后会失去什么，再决定清哪一层。

缓存、状态和数据不是一回事

类型 常见内容 删除后会发生什么 默认处理
缓存 缩略图、编译输出、可重新下载的副本 首次打开变慢，并增加耗电和流量 先确认归属，再用应用自己的清理入口
状态或会话 窗口、标签页、Cookie、草稿、登录令牌 丢失工作现场、登录状态或离线连续性 保留，除非应用提供明确的重置项
数据库或索引 .db、.sqlite、加密索引、内容寻址目录 可能丢失搜索、离线记录或唯一的本地副本 只有所有者明确说明可重建时才处理
个人数据 文稿、照片、邮件、聊天、模型和凭据 永久丢失，或需要付出大量下载成本 不按缓存处理
一次缓存查询会进入命中或未命中分支，未命中时重新获取源数据并建立缓存
缓存未命中时，应用会重新获取源数据并生成副本。

同一个目录里常常三类内容混在一起，所以 ~/Library/Caches 更像一条判断线索，并不能单独证明整棵目录树都可以清空。

适合清理的情况大致有三种：缓存确实占掉了急需的空间，应用的官方排障文档明确要求清理，或者索引已经确认损坏、过期。macOS 和许多应用会在空间紧张时自动淘汰缓存，定期把整棵 Caches 树清空，反而会暂时拖慢启动，并多付一轮耗电和下载量。

Mac 缓存通常在哪里

  • ~/Library/Caches/ 保存当前用户的应用缓存，子目录通常使用 Bundle ID，比如 com.google.Chrome
  • /Library/Caches/ 保存系统范围的缓存
  • /System/... 受到系统完整性保护，不在手动清理范围内

Apple 的文件系统说明明确把 /System/Library 留给系统。不要递归删除任一 Caches 根目录，也不要把权限错误当成给通用清理命令加 sudo 的理由。

Application Support、Containers、Group Containers、偏好设置、钥匙串和隐藏的工具目录，默认都按状态或个人数据处理。只有所有者明确说明其中某个子目录可以重建，才把它归入缓存。

先找出最大的缓存

du -sh ~/Library/Caches/* 2>/dev/null | sort -h
du -sh /Library/Caches/* 2>/dev/null | sort -h

读到权限错误就停下来，不要为了看完整结果加 sudo。~/Library/Caches 只影响当前用户，/Library/Caches 的范围更大，可能服务多个账户或系统组件。 系统设置里的“系统数据”只是没有归入其他类别的汇总，不是一个目录。Apple 的 Mac 存储空间说明也采用这一分类方式，因此测量结果应以具体所有者目录和实际可用空间为准。

删除前先回答五个问题

  1. 这个目录属于哪个应用、命令行工具或系统服务
  2. 所有者能否重建，从哪个原始文件或远端来源重建
  3. 缓存未命中会付出多少编译时间、电量、网络流量和离线能力
  4. 应用、下载器、包管理器或模型服务是否仍在运行
  5. 永久删除前有没有预览、废纸篓或明确的重新下载路径

其中任何一项答不出来，就先保留。

优先使用所有者的清理入口

浏览器

浏览器缓存可能达到数 GB。Chrome 的清除浏览数据说明把缓存图片和文件与历史记录、Cookie、密码、网站设置及离线数据分开。只想释放缓存空间时，只选“缓存的图片和文件”，不要删除整个浏览器配置目录。

开发工具

Xcode Derived Data 可以重建，但重建会消耗时间和电量。Homebrew 先按官方清理说明运行 brew cleanup --dry-run 预览，再决定是否执行 brew cleanup。npm 的缓存会自我修复，应先运行 npm cache verify；npm 缓存文档说明，除非是明确的空间回收或排障，不需要把 npm cache clean --force 当成日常维护。

npm cache verify

AI 工具和下载的模型

hf cache ls
hf cache rm model/example --dry-run
hf cache prune --dry-run

ollama ls
ollama rm <model>

AI 工具尤其要用自己的清理接口。Hugging Face 先用 hf cache ls 查看模型和版本，再用 hf cache rm model/example --dry-run 或 hf cache prune --dry-run 预览，具体参数以 Hugging Face 缓存命令为准；Ollama 先用 ollama ls 查看模型，再按 Ollama CLI 说明用 ollama rm <model> 删除明确选中的模型。模型是主动下载的内容，不是普通 缓存，聊天记录、凭据、会话、配置和仍在使用的数据库也不能顺手清掉。

清理前先退出对应应用，因为运行中的应用可能正在写入，或以内存映射方式使用缓存，直接删文件会把缓存数据库弄坏。浏览器里的 Cookie、网站数据、历史记录、密码和页面缓存是不同选项，只想释放空间时选缓存内容即可，清除全部浏览数据可能让网站退出登录，却不一定多腾出多少空间。

清理完成页面显示实际释放 86.4 GB，并说明缓存已经清理
清理完成后显示实际释放的空间。这是 Mole 的“清理”视图。

手动清理没有问题，只是 Bundle ID 和目录名不总是好认。清理工具最好在操作前就把归属、路径、大小和类别摊开，默认排除配置、文稿、模型目录和聊天记录。Mole 的“清理”视图采用清理前确认的方式，明确哪些内容会跳过，并对每条路径重新验证，这比扫描出多少文件更重要。

仍需手动处理时

手动处理应该放在最后：退出所有者和相关后台进程，只把一个已经确认的缓存子目录移到废纸篓，重新打开应用并重复原来的工作，再检查文稿、登录、离线数据、偏好、构建产物和模型是否仍正常。Apple 的 Mac 存储空间说明提醒，文件移到废纸篓后，只有清空废纸篓才会真正释放空间。这个延迟正好提供恢复窗口。

Mole 的开源命令行工具在 lib/clean 中展示了类似检查，原生 App 用 Swift 实现同类规则。

缓存候选项先经过有超时的容量检查和安全规则，再进入确认，运行中的工具、保护文件和受保护目录会让它被跳过
工具状态、保护文件和受保护目录会决定候选项进入确认，还是留在原位。

较稳妥的实现会优先调用包管理器自己的清理接口，避开仍被后台服务使用的构建缓存，对解析后的路径再次验证，并为缓慢的容量探测设超时。所属工具不存在、路径含义不清，或目录被明确保护时，保留比猜测更合适，递归删除整个 Caches 目录会绕过这些判断。

  • AI 助手的聊天历史和对话记录
  • 偏好设置和保存的登录信息
  • /System 下的内容
  • 无法确认用途的目录

为什么缓存和系统数据还会长回来

一个相对容易复核的顺序是：先测量大小和归属，退出应用，再用应用自己的存储设置或清理命令，一次只处理一个类别。重新打开应用，确认登录、离线内容和项目仍正常后，再清空废纸篓。偏好设置、描述文件、聊天、文稿，以及含义不明的 Application Support 数据，本来就不算缓存。

缓存重新长回来通常是正常现象，应用会重新下载文件、生成缩略图、编译输出和建立索引。下一次启动因此可能暂时多用 CPU、电量、网络和磁盘。系统设置里的“系统数据”是没有归入其他类别的总和，不是一棵可以直接删除的目录，统计也可能晚于真实文件变化。清理后看实际可用空间和应用是否正常，不要为了追一个延迟更新的分类继续扩大删除范围。