APFS不支持传统硬链接，改用克隆机制：克隆共享数据块、独立inode与元数据、触发写时复制；符号链接完全兼容，用于路径跳转；二者不可混用判断文件等价性。
APFS 文件系统不支持传统意义上的硬链接。
APFS 用“克隆”替代硬链接的核心逻辑
APFS 的设计摒弃了 Unix 风格的硬链接机制，根本原因在于其底层采用写时复制（Copy-on-Write, CoW）策略。当用户“复制”一个文件时，APFS 并不立即拷贝数据块，而是创建一个指向相同数据块的全新文件记录，并标记为“共享”。这个操作就是文件克隆（File Clone）。
它在行为上接近硬链接：多个克隆体共享原始数据、修改任一副本会触发实际拷贝（仅影响被改部分）、节省空间、删除一个不影响其他副本的数据存在。但它不是硬链接——每个克隆体拥有独立的 inode、独立的元数据（如修改时间、扩展属性、ACL），且可跨卷克隆（只要源和目标在同一个 APFS 容器内）。
所以 macOS 上你无法用 ln 命令为普通文件创建硬链接，系统会报错 Operation not supported。这不是权限或路径问题，而是 APFS 文件系统本身不实现该功能。
部署和使用军舰的 macOS Automator 自动化服务集合。包含 5 个实用工作流：PDF转JPG、PNG重命名并转JPG、图像拼接、解压RAR、顺序命名图像文件。一键安装所有服务到 ~/Library/Services/ 目录。使用场景：(1) "安装我的自动化服务"，(2) "部署所有 Automato...
符号链接在 APFS 中完全可用，且行为标准
符号链接（软链接）是纯路径字符串存储，与底层文件系统数据结构无关。因此 APFS 完全兼容符号链接，创建、解析、跟随行为与 HFS+ 或 ext4 一致。
- 用
ln -s /path/to/target linkname创建，目标可以是任意路径（本地、挂载卷、甚至不存在的路径） - 可指向目录，也可跨文件系统（比如从 APFS 卷链接到 ExFAT 外置盘上的文件）
- 目标被移除后，符号链接变为悬空（dangling），
ls -l会显示红色并带->箭头 - 权限、所有者、时间戳等元数据属于链接文件自身，与目标无关
实际应用中该怎么选：克隆 vs 符号链接
关键看你要解决什么问题：
-
需要多份“看起来独立、实则共享初始数据”的文件副本（如版本快照、测试备份）→ 用
cp --clone或 Finder 的 Option-drag。这是 APFS 原生推荐方式，安全、高效、自动触发 CoW。 -
需要快速跳转到某路径，或模拟快捷方式/统一入口（如
/usr/local/bin/mytool指向实际安装位置）→ 用符号链接。它轻量、灵活、语义清晰。 - 想让两个路径完全等价、共享所有元数据（包括修改时间、权限变更同步）→ APFS 不支持，硬链接在此不可用。这类需求在 macOS 上基本无解，需换用其他支持硬链接的文件系统（如通过虚拟机挂载 ext4）或接受克隆的元数据分离特性。
开发者和脚本编写者注意
不要在 macOS 脚本中假设 ln 能创建硬链接。检测是否为同一文件内容，请用 stat -f "%i" file1 file2 对比 inode —— 但要注意：克隆文件的 inode 一定不同，即使内容未变；而符号链接的 inode 是它自身的，不是目标的。
若需判断两个文件是否“实质相同”，更可靠的方式是：cmp -s file1 file2（二进制比较）或基于哈希（shasum -a 256）。APFS 克隆不会影响这些结果，因为数据块物理一致。
