apfs校验和仅保护元数据（如inode、目录项等）静止状态下的完整性，防止静默损坏，不保障传输过程或用户文件内容的完整性；启用需新建卷时指定--checksums，系统卷不支持后期开启。
APFS 文件系统本身不负责“数据传输过程”中的完整性（比如网络传文件、USB拷贝时的实时校验），它保障的是数据落盘后、在存储介质上静止状态下的完整性。所谓“校验和机制”，是 APFS 内建的元数据保护能力，核心目标是防止静默损坏（silent corruption）——即磁盘物理错误、固件异常或断电导致的数据块悄然变脏，而系统却毫无察觉。
它不干预传输链路，但一旦数据写入 APFS 卷，校验和就立刻生效。
校验和只作用于元数据，不是所有文件内容
APFS 默认为元数据块（如 inode、目录项、快照头、B-tree 节点等）计算并存储 CRC-32C 校验和。这些结构控制着“文件在哪”“目录怎么组织”“快照指向哪”，一旦出错，整个卷可能无法挂载或目录错乱。
但普通用户文件（如 .docx、.jpg）的数据块默认不带校验和——除非你用 diskutil apfs addVolume 创建新卷时显式启用 --checksums（仅限 macOS 12+，且需全新格式化，系统卷不支持此选项）。
你可以用这条命令确认当前系统卷是否启用元数据校验和：
diskutil apfs list | grep -A5 "Macintosh HD" | grep "Checksums"
输出 Checksums: Yes 表示已启用；若为 No，说明该卷是从 HFS+ 升级而来，无法后期开启。
写入时生成，读取时验证，出错自动响应
校验和不是事后扫描工具，而是 APFS I/O 流程的一部分：
- 每次写入元数据块，系统同步计算校验和，并与数据块一同写入闪存
- 每次读取元数据块，APFS 自动比对校验和；若不匹配，会尝试从镜像副本（如快照中保留的旧版本）恢复，或直接报错阻止错误传播
- 这个过程完全透明，无需用户触发，也不消耗额外命令行操作
注意：它不修复用户数据块损坏，只防止元数据层面的逻辑崩塌。一张照片文件内容被悄悄改写，APFS 不会发现；但如果它的 inode 被破坏导致 ls 列不出来，校验和就能拦住。
真正保障传输完整性的组合动作
要覆盖“从 A 传到 B”的端到端完整性，需跳出 APFS，配合其他层：
-
传输前：对源文件算
shasum -a 256 file.zip，记录哈希值 -
传输中：使用支持校验的协议（如 rsync 的
--checksum、或scp -o CheckHostIP=yes配合签名） -
传输后：在目标端重新计算哈希，比对一致；再用
hdiutil verify image.dmg检查磁盘映像内部结构 - 落地后：若存为 APFS 卷上的文件，依赖其元数据校验和防后续静默损坏
APFS 的校验和，是守门人，不是快递员。它不管你怎么送，只确保送到之后，东西没在仓库里自己烂掉。
