# Mac 的 Library Containers 是什么，哪些内容该留着

> 核对容器对应的应用，分清缓存、设置和个人数据，一次只改一个能补回的位置，别把删除整个容器当成清缓存。

Published: 2026-05-13 | Updated: 2026-10-31

`~/Library/Containers` 里某个文件夹很大，先查清它属于哪个应用、存了什么，不要直接删掉整个文件夹，沙盒容器里可能既有缓存，也有设置、数据库和文档，真正要看的是哪个子目录占空间，以及里面的内容还能不能重新获得。

## Library Containers 里装的是什么

Apple 的 [App 沙盒说明](https://developer.apple.com/documentation/security/accessing-files-from-the-macos-app-sandbox)介绍了容器的来历，沙盒应用第一次启动时，macOS 会在 `~/Library/Containers` 为它创建容器，可以把它理解为应用存放本机数据的独立家目录，与应用本体分开。

容器里经常需要检查的是 `Data/Library`，Apple 的[文件系统说明](https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html)区分了支持数据、偏好设置和缓存，比起上级目录有多大，先看用途更有帮助。

| 容器内的位置 | 用途 | 清理时怎么选 |
| --- | --- | --- |
| Data/Library/Caches | 应用应该能重新生成的数据 | 只考虑已经确认、可以补回的缓存内容 |
| Data/Library/Application Support | 支持数据，可能包括数据库 | 保留，除非明确要移除这个应用的数据 |
| Data/Library/Preferences | 应用偏好设置 | 清缓存时保留 |
| Data/Documents | 应用保存的文档 | 保留，或先导出并备份 |

它不是 `~/Library/Group Containers`，共享 App Group 文件夹要核对另一种归属关系，见 [Group Containers 说明](https://mole.fit/zh/blog/what-is-group-containers-mac)。

## 先打开看看，不改文件

在访达里用**前往 › 前往文件夹**，粘贴下面的路径，操作见 Apple 的[文件夹导航说明](https://support.apple.com/en-gb/guide/mac-help/mchlp1236/mac)。

```text
~/Library/Containers
```

`~` 表示你的个人文件夹，一次检查一个容器和它的子目录，改动前记下完整位置和大小，读不到的文件夹只能算未知，不能当成空的。

Apple 的沙盒文档说明，macOS 14 及后续版本中，一个应用访问另一个应用的容器时可能会请求许可，访问被拒绝就停在这里，不改权限，也不换删除命令再试。

## 用 Bundle Identifier 核对应用

反向域名格式的名称是辨认线索，不是删除指令，找到可能对应的已安装应用后，核对它的标识符，不只看显示名称像不像。

1. 在访达里找到怀疑对应的应用，用右键菜单查看程序包内容，Apple 的[程序包说明](https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/AboutBundles/AboutBundles.html)介绍了这个入口。
2. 找到 `Contents/Info.plist`，只读，不编辑。
3. 对照 `CFBundleIdentifier` 和容器名称，Apple 的[属性列表参考](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html)说明了这个键。
4. 对不上就保留容器，再查厂商文档，辅助程序或扩展可能有自己的标识符。

不要为了让名称对上就重命名容器，也不要编辑应用的属性列表，名称看不懂、归属仍不确定时，凭猜测对上的应用不足以作为删除依据。

## 先查为什么变大

选操作前先比子目录，缓存大和文档库大，需要做的决定不同，即使它们都在同一个容器里。

Caches 占大头，就先找应用自己的缓存或存储管理入口，Application Support 或 Documents 占大头，就去应用里检查下载、附件和保留的文档，只在那里移除已经不需要的内容。

邮件、信息、备忘录这类应用按个人资料库对待，不当成一堆随手能删的缓存，也不要假设容器里就是它们的全部数据，或者重新登录就能补回删掉的一切。

通用的缓存判断可以看[哪些 Mac 缓存可以删除](https://mole.fit/zh/blog/which-mac-caches-are-safe-to-delete)，这次只围绕已经确认的应用检查，不顺手清其他 Library 文件夹。

## 只改一个缓存位置，再核对结果

只有应用文档或自己的管理入口确认这份缓存能重建，所需的源文件或下载也还可用时才继续，Apple 的文件系统说明把 Caches 定义为可重新生成的数据，但文件夹名称不能证明应用真的把所有东西都放对了。

1. 退出应用，为无法重新获得的数据单独保留备份。
2. 只把已经确认的缓存子目录移到废纸篓，容器本身和其他数据留在原处。
3. 重新打开应用，用真实文档或任务检查，离线要用的内容也试一次。
4. 再量同一个文件夹，检查通过之前保留移除的项目。

移到废纸篓还不等于释放了磁盘空间，Apple 的[删除与恢复说明](https://support.apple.com/en-nz/guide/mac-help/-mchlp1093/mac)介绍了项目仍在时怎么放回去，测试不通过就先退出应用再恢复原项目，遇到新生成的数据不要直接覆盖，先核对内容。

正常使用时缓存还会增长，如果刚建好就很大，继续清可能只是在重复同样的工作，这时回到应用里看保留的内容，不扩大删除范围。

## 不移除应用数据，就留下整个容器

删掉已安装应用的整个容器，拿掉的是它的本机数据目录，可能重置偏好设置、丢掉保存的数据，不是只清缓存，重新生成一个空容器也找不回旧数据库和文档。

已卸载应用的容器可能是残留，但没看到熟悉的应用名称，不足以证明它已经没人用，先核对归属、是否还有残留的辅助程序或扩展，以及以后重装是否还想保留数据，再决定移除。

想留的内容先独立备份，或者用应用支持的导出方式保存，账号同步不是另一份备份，重装也不保证恢复只存在本机的内容，废纸篓里的原项目还在时，才有从那里恢复的机会。

## Mole 会列出什么

Mole Mac 的**清理**会在 **App 缓存与日志**里列出应用容器内符合条件的 `Data/Library/Caches` 子项，这一路扫描需要完全磁盘访问权限，会经过缓存安全与白名单检查，不会把整个 Containers 文件夹当成缓存目标。

通用容器缓存扫描会跳过邮件、信息和备忘录的容器，删除检查里也保护了这些路径，卸载扫描则可以把容器残留关联到选中的应用，这部分按应用数据单独确认，不和清缓存混在一起，未勾选表示留给你检查，不代表选中以后还能保住里面的内容。

## 常见问题

### Library Containers 里的东西能全部删除吗？

不能，这里既有缓存也有应用数据，先确认一个归属、一个能补回的缓存子目录，不删上级目录。

### 重新安装应用会恢复容器吗？

可能会创建新的本机容器，但不会因此找回删掉的设置、文档和本机数据库，恢复需要可用的备份、导出，或者废纸篓里还在的原项目。

### 为什么 Mole 显示的比整个容器小？

符合条件的缓存子项，范围本来就比整个容器小，访问权限、缓存安全与白名单也会影响清理能列出什么，扫描结果不是应用全部数据的总量。

---

Canonical HTML page: https://mole.fit/zh/blog/what-is-library-containers-mac
Blog index for agents: https://mole.fit/zh/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
