std::filesystem::equivalent能判断硬链接同源，因其在POSIX系统比较inode、Windows系统比较卷序列号与文件索引，而硬链接共享同一inode或文件索引，故指向同一实体即返回true；要求两路径均存在且可访问，否则抛出filesystem_error。
std::filesystem::equivalent 为什么能判断硬链接同源
std::filesystem::equivalent 的底层逻辑是通过比较两个路径对应的文件系统对象的 device ID + inode number（POSIX）或 volume serial number + file index（Windows）来判定是否指向同一文件实体。硬链接共享相同的 inode（Linux/macOS）或文件索引（Windows），因此只要两个路径解析后指向同一物理文件，equivalent 就返回 true——它不关心路径字符串是否相同，也不依赖符号链接展开与否，只认底层存储实体。
注意：该函数要求两个路径都存在且可访问；若任一路径不存在、无权限或为悬空符号链接，会抛出 std::filesystem::filesystem_error。
调用前必须确保路径已解析且不包含符号链接干扰
硬链接判断本身不受符号链接影响，但如果你传入的是带符号链接的路径，equivalent 默认会跟随符号链接（即解析目标文件）。这可能导致误判：比如 a.txt 是硬链接，link_to_a 是指向它的符号链接，那么 equivalent("a.txt", "link_to_a") 仍为 true（因为最终都落到同一 inode），但这不是你在验证“硬链接关系”，而是“是否同源文件”。要严格聚焦硬链接，应避免混入符号链接路径。
- 使用
std::filesystem::canonical()或std::filesystem::absolute()预处理路径，确保传入的是真实路径而非符号链接中间态 - 若需排除符号链接参与判断，可用
std::filesystem::is_symlink()提前检查并拒绝 - 不要对路径做字符串比较（如
path1 == path2），这只能判断路径字面量是否一致，完全无法识别硬链接
常见错误：权限不足、跨文件系统、路径未存在
这三个原因占了 equivalent 失败的绝大多数：
立即学习“C++免费学习笔记（深入）”；
-
Permission denied错误：即使文件可读，某些文件系统（如 NFS、某些容器挂载）可能禁止获取 inode 信息；尝试用stat()手动验证是否能读取st_dev和st_ino - 跨文件系统必然返回
false：不同分区/挂载点的文件不可能有相同 inode，这是设计使然，不是 bug - 路径不存在时抛出异常，而不是返回
false；务必用try/catch或先调用exists()检查
示例片段：
try {
bool same = std::filesystem::equivalent("file1.txt", "file2.txt");
// same == true 表示二者是硬链接（或同一文件的多个路径名）
} catch (const std::filesystem::filesystem_error& e) {
// e.code().message() 可能是 "No such file or directory" 或 "Permission denied"
}
Windows 下需注意 ReFS 和某些网络路径的兼容性
NTFS 支持硬链接且 equivalent 行为正常；但 ReFS（Resilient File System）虽支持硬链接，部分旧版运行时可能无法正确提取文件索引。更常见的是 SMB 网络路径：Windows 默认禁用远程服务器上的硬链接解析，equivalent 对跨机器的路径总是返回 false，哪怕它们实际指向同一 NAS 上的同一文件。
- 本地 NTFS 卷上硬链接检测可靠
- UNC 路径（如
\servershare ile1）通常不可靠，建议转为映射驱动器（如Z: ile1）再测 - WSL2 中访问 Linux 文件系统时，
equivalent会走 Linux 内核逻辑，行为与原生一致；但访问 Windows 文件（如/mnt/c/...）时受 WSL2 文件系统桥接限制，可能返回意外结果
exists() 检查或没捕获 filesystem_error，就可能把硬链接误判成普通重复文件。 
