C++如何使用std::filesystem::equivalent判断路径同源性

std::filesystem::equivalent 判断是否指向同一文件系统实体而非路径字符串相等，依赖 st_dev/st_ino，受符号链接、挂载点、网络文件系统等影响，需手动规范化路径并捕获异常。

std::filesystem::equivalent 会返回 false 即使路径指向同一文件

这是最常被误解的点：std::filesystem::equivalent 判断的是「是否指向同一个文件系统实体」，不是「是否字符串相等」或「是否能通过相对路径互相抵达」。它依赖底层系统调用（如 stat() 的 st_dev 和 st_ino），因此符号链接、挂载点、绑定挂载、网络文件系统都可能让它返回 false，哪怕你肉眼觉得“明明是同一个文件”。

• 若路径之一不存在，抛出 std::filesystem::filesystem_error（不是返回 false）
• 跨不同挂载点（比如 /home 和 /mnt/data 即使物理磁盘相同）必然返回 false
• Linux 上两个硬链接到同一 inode 的路径会返回 true；但符号链接需解析后比对目标 inode —— 若未启用 std::filesystem::symlink_option::follow（默认不 follow），则只比较链接文件自身，而非目标
• Windows 上注意：NTFS 卷 GUID 和重解析点行为会影响结果，? 路径和普通路径可能被视为不同设备

必须手动处理路径规范化和异常

std::filesystem::equivalent 不自动做路径规整（比如 ./foo vs foo），也不容忍不存在路径。你得自己先确保路径有效且格式一致，否则直接崩溃或误判。

• 用 std::filesystem::canonical() 或 std::filesystem::absolute() 统一转换为绝对路径再比较，避免相对路径干扰
• 必须用 try/catch 捕获 std::filesystem::filesystem_error，尤其当路径来自用户输入或配置文件时
• 不要假设 equivalent(a, b) 和 equivalent(b, a) 在异常路径下行为对称 —— 如果 a 存在而 b 不存在，前者抛异常，后者也抛，但堆栈位置不同
• 示例安全调用：

bool safe_equivalent(const std::filesystem::path& a, const std::filesystem::path& b) {
    try {
        return std::filesystem::equivalent(
            std::filesystem::canonical(a),
            std::filesystem::canonical(b)
        );
    } catch (const std::filesystem::filesystem_error&) {
        return false;
    }
}

替代方案：什么时候不该用 equivalent

如果你真正想判断的是“这两条路径是否能访问到相同内容”，equivalent 往往不是答案。它太底层、太严格，且不可移植。

• 想确认两个路径是否指向相同逻辑资源（比如配置文件别名）？用 std::filesystem::read_symlink() 手动展开符号链接后比对目标路径字符串
• 想校验文件内容一致性？用 std::filesystem::file_size() + 哈希（如 std::hash<std::string_view> 配合 std::ifstream 读块）
• 只想判断路径字符串是否等价（忽略大小写、斜杠风格）？直接用 std::filesystem::path::lexically_normal() + 自定义字符串比较
• 在容器镜像或 CI 环境中，/proc/self/root 下的路径可能让 equivalent 行为突变 —— 这类场景建议回避，改用明确的挂载点声明

Windows 上的 symlink_option 需显式指定

Windows 默认不解析符号链接（symlinks），equivalent 会把链接文件本身当作独立实体比较。这意味着 equivalent("link.txt", "target.txt") 在 Windows 上几乎总是 false，除非你告诉它要 follow。

立即学习“C++免费学习笔记（深入）”；

• 正确写法是传入第三个参数：std::filesystem::equivalent(a, b, std::filesystem::symlink_option::follow)
• 但注意：这要求调用进程有 SE_CREATE_SYMBOLIC_LINK_PRIVILEGE 权限，否则 canonical() 可能失败，进而导致 equivalent 抛异常
• MinGW 和 MSVC 对 symlink 支持程度不同 —— MinGW 默认禁用 symlink，即使路径存在 link 文件，follow 也会静默失效
• 没有权限又必须比较目标？改用 GetFinalPathNameByHandle（Windows API）手动解析，再比对结果路径

实际用的时候，别把它当“路径相等函数”用。它是个窄口径的底层设施，只适合明确需要 inode 级别判定的场景，比如防止 hardlink 循环、校验备份源目标是否意外重叠。其他情况，多数时候你真正想要的只是更可控的字符串规整或内容哈希。