apfs克隆初始不占额外物理空间，前提是源与克隆未修改且共享数据块；一旦任一副本写入，触发写时复制（cow），即分配新块并开始占用空间。
克隆文件物理空间是否占用，看inode和写时复制状态
APFS克隆不立即占空间，但“不占”是有条件的：源与克隆体都未被修改，且共享同一组数据块。一旦任一副本发生写入（哪怕只改一个字节），APFS会触发写时复制（CoW），为变更块分配新位置——此时物理空间开始增长。
验证是否仍处于“零占用”状态，最直接方式是比对inode和观察后续写入行为：
-
ls -i /path/to/original /path/to/clone：若输出中两个inode号相同，说明尚未触发CoW，仍是纯克隆；一旦不同，说明已分离，空间占用开始独立 -
stat -f "%z %i" /path/to/file：定期采样可捕获大小（%z）与inode（%i）变化，比du更准——因为du对克隆体返回逻辑大小，而非实际块占用 - 小修改后用
df -h /秒级轮询：若仅增长KB级而非整个文件大小，基本可确认CoW生效，克隆机制仍在起作用
实时监控克隆体空间膨胀，避开df刷新延迟陷阱
df -h显示的是卷级快照，刷新慢、聚合统计，无法捕捉克隆体首次写入那一瞬间的块分配。真正有效的实时监控必须组合底层工具：
-
sudo fs_usage -w -f filesys | grep "write.*data"：高亮所有写入数据块的操作，克隆体第一次保存时，你会看到密集的write调用，对应新块分配 -
diskutil apfs listFiles /dev/disk1s1 | grep -A2 "your_file_name"（需替换为实际设备标识）：查看文件是否被标记为cloned，以及其extent引用是否与源一致 - 写入前/后运行
diskutil apfs list | grep -A5 "Container"：对比Used字段变化，比df更贴近容器层真实用量
注意：fs_usage需sudo权限，且输出滚动极快，建议配合grep过滤或重定向到文件分析。
删除克隆源文件后，目标文件还能用吗
能，只要克隆已完成且未出错。APFS通过引用计数保障数据安全：源与克隆体各自拥有独立元数据（路径、权限、时间戳、扩展属性），但底层数据块被共同引用。删除源只是减少一个引用，只要克隆体还存在，数据块就不会被回收。
但以下情况例外，容易踩坑：
- 克隆操作未完成就删源（如
cp --clone中途被Ctrl+C中断）：此时目标可能为空或损坏，ls -l会显示0字节，cat报Input/output error - 目标路径不在APFS卷上（如拷贝到外置exFAT硬盘）：系统静默回退为普通拷贝，删源不影响目标，但也不省空间——这不是克隆，是假象
- 跨宗卷（volume）操作：APFS容器内多个卷共享空间，但克隆只在单卷内有效。跨卷拖拽即使按住Option，也不会克隆，而是全量拷贝
为什么“空间明明够却提示不足”，Purgeable Space是隐形关键
你看到df -h显示还有20GB可用，Time Machine或安装更新却报错“空间不足”，大概率是Purgeable Space被计入“已用”，但未开放给应用使用。这部分空间被系统标记为“可清除”，但不会自动释放给任意进程。
查它、动它，靠这几条命令：
-
diskutil info / | grep -E "(Available|Purgeable)"：明确看到Purgeable值，比如Purgeable: 12.4 GB -
tmutil listlocalsnapshots /：本地快照是Purgeable大户，用tmutil deletelocalsnapshots [name]可手动清 -
sudo rm -rf /.DocumentRevisions-V100：慎用！这是文档版本历史缓存，通常由系统管理，强制删可能影响Time Machine一致性
真正难处理的是邮件附件、照片缩略图这类用户态Purgeable数据——它们不暴露路径，只能靠邮件偏好设置里关掉“自动下载附件”，或进照片设置里选“优化Mac存储”来间接控制。
