应通过高层API（如NSFileManager、NSURL）或mdfind/mdls命令访问APFS目录，禁用直接解析元数据；沙盒应用需NSFileCoordinator协调；高频场景推荐FSEvents监听+增量缓存。
APFS（Apple File System）在 macOS 中的元数据结构高度优化且加密封装，直接遍历目录元数据不推荐也不可行——系统未提供公开、稳定、支持用户态直接解析的 APFS 元数据接口。所有合法、安全、可持续的目录访问都应通过 macOS 提供的高层 API 或命令行工具完成。
优先使用 NSURL 和 NSFileManager（沙盒/非沙盒应用）
这是 Apple 官方推荐且长期支持的方式，自动适配 APFS 的内部优化（如克隆、快照、硬链接处理），无需关心底层 B-tree 结构或 extent 记录：
- 用 NSFileManager enumeratorAtURL:includingPropertiesForKeys:options:error: 遍历目录，支持惰性加载、符号链接策略控制、批量属性预取（如 creationDate、fileSize、isRegularFile）
- 对性能敏感场景，可结合 NSURLResourceKeys（如 NSURLTotalFileSizeKey、NSURLContentModificationDateKey）一次性获取多个属性，避免多次 stat
- 沙盒应用必须使用 NSFileCoordinator 协调读取，防止因快照或延迟写入导致元数据不一致
命令行下用 mdfind + mdls 替代 find / ls -l
APFS 与 Spotlight 深度集成，mdfind 查询基于元数据索引（而非实时扫描目录树），速度远超传统遍历：
- mdfind "kMDItemDisplayName == '*log' && kMDItemContentTypeTree == 'public.data'" —— 快速定位匹配文件，毫秒级响应
- mdls -name kMDItemFSSize -name kMDItemDateAdded /path/to/file —— 直接读取已索引元数据，绕过 stat() 系统调用开销
- 注意：需确保 Spotlight 索引启用（sudo mdutil -i on /），且目标路径不在隐私排除列表中
避免直接解析 APFS 容器或卷头结构
APFS 卷的元数据（如 omap、space manager、snapshot tree）由内核私有驱动管理，格式随 macOS 版本频繁变更：
- 第三方工具（如 apfs-fuse、apfs-dump）仅适用于只读调试，无 Apple 支持，macOS 升级后极易失效
- 内核扩展（KEXT）方式读取元数据在 macOS 10.15+ 受严格限制（需公证+用户授权），且 Catalina 起系统卷默认加密并挂载为只读
- 即使通过 diskutil apfs list 获取卷信息，其输出仍是抽象层视图，不暴露 B-tree 节点地址或 extent 映射细节
高频遍历场景的实用建议
若应用需频繁扫描特定目录（如备份监控、IDE 项目索引），应规避全量递归，转为增量与事件驱动：
- 用 FSEvents API（或 Swift 的 FileManager.startMonitoring）监听目录变更，仅处理新增/修改/删除事件
- 维护轻量级本地缓存（如 SQLite 表），记录上次扫描时的 NSURLContentModificationDateKey 和 NSURLFileIdentifierKey，下次仅比对变更项
- 对大型目录，启用 NSDirectoryEnumerationSkipsPackageDescendants 和 NSDirectoryEnumerationSkipsHiddenFiles 减少无关节点遍历
