find 在 apfs 上遍历目录元数据特别慢，因其默认递归会反复 stat 条目，触发大量元数据解析、硬链接计数及克隆视图合并，尤其在含大量小文件、time machine 快照或符号链接时卡在 getattrlistbulk 系统调用。
为什么 find 在 APFS 上遍历目录元数据特别慢
APFS 的目录快照（snapshot）和克隆（clone）机制让元数据结构比 HFS+ 更复杂，find 默认递归时会反复 stat 每个条目、触发大量元数据解析与硬链接计数计算。尤其当目录含大量小文件、稀疏文件或 Time Machine 本地快照残留时，find . -name "*.log" 可能卡在 getattrlistbulk 系统调用上——这是 macOS 内核在 APFS 层聚合读取元数据的瓶颈点。
- 默认
find不跳过不可访问目录，遇到挂载点或权限受限子树会阻塞等待（而非快速失败） -
stat()调用在 APFS 上开销更高，因为需合并克隆来源的元数据视图 - Time Machine 本地快照（
.fseventsd,.PKInstallSandboxManager等隐藏目录）含大量符号链接与伪文件节点，触发额外路径解析
用 mdfind 替代 find 加速元数据检索
mdfind 直接查 Spotlight 元数据索引，绕过文件系统遍历，对已索引路径几乎是常数时间响应。它不适用于未启用 Spotlight 的卷（如外置 NTFS 卷），但对系统盘 / 用户主目录效果显著。
- 要查文件名：用
mdfind "kMDItemDisplayName == '*error*.log'"，注意通配符需加引号且用双等号 - 限定路径范围：加
-onlyin /Users/you/Documents避免跨卷扫描 - 禁用实时索引干扰：临时关闭 Spotlight 索引更新可减少锁竞争，执行
sudo mdutil -i off /（之后记得开回） - 若结果为空，先确认索引是否就绪：
mdutil -s /应返回 “Indexing enabled.”
用 getfattr 或 xattr 绕过完整 stat 获取关键元数据
很多场景其实只需要修改时间、文件大小或扩展属性（如 com.apple.lastuseddate#PS），不必走完整 stat() 流程。APFS 对 xattr 访问做了优化，比全量元数据解析快 3–5 倍。
- 只读修改时间：
xattr -p com.apple.FinderInfo path/to/file 2>/dev/null | head -c 8 | xxd -p -r | od -t x4（提取 Finder 时间字段） - 批量获取大小与 mtime（避免
ls -laR）：find . -type f -print0 | xargs -0 stat -f "%z %m %N" 2>/dev/null，其中-f指定格式，%z是大小，%m是修改时间秒级戳 - 慎用
ls -lR：它隐式调用stat()+getpwuid()+getgrgid()，在 APFS 上易因用户组数据库查询拖慢
禁用不必要的 APFS 特性降低元数据开销
如果机器不依赖 Time Machine 本地快照或文件克隆（如开发机、CI 构建节点），可关闭部分 APFS 功能减少元数据层负担。
- 停用本地快照：
sudo tmutil disablelocal，删除已有快照：sudo tmutil thinlocalsnapshots / 9999999999 1 - 挂载时禁用克隆（仅限非系统卷）：
sudo diskutil apfs updatePreboot /dev/diskXsY && sudo mount -o nobrowse,noatime,noclone /dev/diskXsY /mnt，其中noclone是关键 - 避免在脚本中频繁创建空目录：
mkdir -p触发的 APFS 目录初始化比 HFS+ 多约 20% 元数据写入，批量创建建议用mkdir单次完成
APFS 元数据优化的关键不在“加速遍历”，而在“避免遍历”——真正耗时的是内核态元数据聚合，不是用户态循环。跳过它，比调优循环快一个数量级。
