macos沙盒容器无硬性大小限制，但实际空间受限于磁盘容量和apfs机制；真正问题在于应用无节制写入导致单个容器膨胀数十gb，拖慢系统并挤占更新空间。
macOS 对沙盒应用的容器（~/Library/Containers/）本身不设硬性大小限制，但实际可用空间受限于系统整体磁盘容量和 APFS 卷管理机制。真正影响使用体验的，是应用在沙盒内无节制写入缓存、数据库、媒体副本等数据，导致单个容器膨胀至数十 GB，最终拖慢系统、挤占更新空间。
部署和使用军舰的 macOS Automator 自动化服务集合。包含 5 个实用工作流：PDF转JPG、PNG重命名并转JPG、图像拼接、解压RAR、顺序命名图像文件。一键安装所有服务到 ~/Library/Services/ 目录。使用场景：(1) "安装我的自动化服务"，(2) "部署所有 Automato...
沙盒容器的数据存储特点
- 每个 App（尤其是 App Store 下载的）独占一个
com.company.app命名的子目录，包含完整运行时环境。 - 数据默认隔离存储：
Data/Library/Caches、Data/Library/Application Support、Data/Library/Preferences等路径均受沙盒保护，外部无法直接修改。 - 卸载 App 时，系统不会自动删除其容器目录——残留文件全部计入“系统数据”，这是“系统数据”异常飙升的主因之一。
- 部分应用（如微信、Notion、飞书）会在
Application Support中保存多份聊天记录、离线文档、缩略图库，且不提供内置清理入口。
控制容器数据增长的实用方法
定期清空活跃容器的缓存子目录
进入~/Library/Containers/com.tencent.WeChat/Data/Library/Caches，全选内容（不删 Caches 文件夹本身）并移入废纸篓；重启应用后会重建必要缓存，但体积大幅缩减。
同样适用于com.dingtalk.mac、com.larksuite.feishu等高缓存应用。删除已卸载 App 的完整容器目录
在~/Library/Containers中按“大小”排序，对照当前 Launchpad 或/Applications列表，识别出名称匹配但主程序已不存在的文件夹（如com.zoom.us、com.microsoft.teams），直接删除整个目录。重定向第三方应用的数据目录（需支持）
少数应用（如某些 Electron 或 Tauri 应用）允许通过启动参数或配置文件指定--data-dir路径。可将其指向外置 SSD 的专用目录，避开沙盒空间压力。用 Pearcleaner 工具精准关联清理
拖入 App 图标后，它能扫描出该应用在Containers、Caches、Application Support、Preferences四处的全部关联项，支持勾选清理，误删率低于 0.3%，比手动更安全高效。
不推荐的操作
- 不要手动修改
Containers目录权限或禁用沙盒——会触发 Gatekeeper 拒绝启动，甚至导致系统完整性保护（SIP）告警。 - 避免用
sudo rm -rf批量清空整个Containers——可能误删正在使用的应用数据，造成登录失效或文档丢失。 - 不要依赖“清倒垃圾”类清理软件自动扫描
Containers——多数缺乏 Bundle ID 匹配逻辑，容易漏判或错删。
沙盒不是瓶颈，失控的数据积累才是。关键在建立定期归档+选择性清缓存的习惯，而不是等“系统数据”爆到 100GB 再手忙脚乱。
