macos 真正的系统级数据压缩分为内存压缩与文件系统级压缩：内存压缩默认使用苹果自研 lzfse 算法，高效平衡速度与开销；apfs 虽支持透明压缩但默认不启用，仅限少数系统内部场景；用户手动压缩属应用层归档，与系统机制无关。
macOS 存储系统中真正起作用的数据压缩，并非用户手动打包时用的 ZIP 或 7z，而是系统级、透明运行的内存压缩与文件系统级压缩机制。它不依赖你点击“压缩”，而是在后台持续优化资源使用——重点在内存管理与磁盘空间节省两个层面。
内存压缩：LZFSE 是主力，不是 ZIP
从 macOS 10.11（El Capitan）起，系统内建的 COMPRESSION_LZFSE 成为内存压缩默认算法。它由苹果自研，专为移动和桌面设备平衡速度与压缩率而设计：
- 比传统 zlib 更快的解压速度，适合高频内存页读写
- 压缩率略低于 LZMA，但 CPU 开销显著更低，避免拖慢前台响应
- 所有“已压缩内存”指标（见活动监视器）都来自 LZFSE 实时处理，而非磁盘上的 ZIP 文件
文件系统级压缩：APFS 支持透明压缩，但默认不启用
APFS（Apple File System）原生支持压缩属性（com.apple.decmpfs），但 macOS 并未对普通用户文件自动开启。它只在极少数系统内部场景使用，例如：
- iCloud 同步元数据临时缓存
- 部分系统日志归档（如 /var/log/asl/ 中的部分条目）
- App Store 下载的 app 包体，在安装前可能以压缩流形式暂存
用户无法通过 Finder 或终端命令直接触发 APFS 压缩；ditto --hfsCompression 等旧接口仅适用于 HFS+，且已弃用。
用户可见的“压缩”其实是归档行为，与系统压缩无关
你在 Finder 右键选“压缩”，或用 zip -9、tar -zcvf，这些都属于应用层归档操作：
- 生成的是独立文件（.zip/.tar.gz），不改变原始文件，也不影响系统内存或 APFS 行为
- 算法取决于工具：zip 默认 Deflate，Keka 选 7z 用 LZMA2，pigz 替代 gzip 用多核 zlib
- 对 JPEG、MP4、PDF 等已压缩格式几乎无效——这不是算法不行，而是数据本身熵值低
开发者可用的压缩 API：compression.h 提供统一接口
苹果在 compression.h 中封装了多种算法供程序调用，包括：
- COMPRESSION_LZFSE：推荐用于 iOS/macOS 应用内实时压缩（如网络传输、本地缓存）
- COMPRESSION_ZLIB：兼容性最强，适合跨平台数据交换
- COMPRESSION_LZMA：高压缩率场景（如固件更新包），但耗 CPU
- COMPRESSION_LZ4：极致速度优先，适合日志流或内存镜像快照
这些 API 不参与系统内存管理，但能帮你构建更省流量、更小体积的应用数据管道。
