std::filesystem::equivalent在硬链接场景下可靠，因其底层比较POSIX的device+inode或Windows的卷序列号+文件索引，硬链接共享同一实体故返回true；但要求两路径均存在、可访问且不跨文件系统，否则抛出filesystem_error。
std::filesystem::equivalent 在硬链接场景下是否可靠
它在大多数主流平台（Linux/macOS/Windows）上对硬链接有效，但行为依赖底层 OS 支持和 std::filesystem 实现质量。GCC 11+、Clang 12+ 和 MSVC 2019 16.10+ 均已通过 POSIX 或 Win32 API 正确转发硬链接的 inode（或等价标识），但旧版本可能 fallback 到路径字符串比较 —— 这会导致误判。
调用前必须确保两个路径都存在且可访问
std::filesystem::equivalent 遇到任一路径不存在、无权限读取或为 dangling symlink 时会抛出 std::filesystem::filesystem_error。硬链接本身不保证目标文件仍存在，所以不能跳过 existence 检查。
- 先用
std::filesystem::exists(path)和std::filesystem::is_regular_file(path)双重验证 - 避免传入
std::filesystem::path("")或相对路径未 resolve 的情况（比如"./file"和"../dir/file"可能因工作目录不同而失败） - 推荐统一用
std::filesystem::canonical()归一化路径再传入 —— 但注意：对硬链接，canonical()返回的是目标文件路径，不是链接自身路径；这反而有助于等价判断
Linux/macOS 下的典型误用：符号链接混入硬链接判断
硬链接和符号链接在语义上完全不同。std::filesystem::equivalent 对硬链接返回 true，但对指向同一目标的两个符号链接默认返回 false（除非目标路径也相同）。若你实际拿到的是符号链接，需要显式 resolve：
// 错误：直接判等两个符号链接路径
std::filesystem::equivalent("a.syml", "b.syml"); // 通常 false
// 正确：先 resolve 再判等（仅当你要比“最终目标是否相同”）
auto a_target = std::filesystem::read_symlink("a.syml");
auto b_target = std::filesystem::read_symlink("b.syml");
std::filesystem::equivalent(a_target, b_target); // 才有意义
硬链接没有“目标路径”概念，它们共享同一 inode，所以无需 resolve —— 直接传原始路径即可。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
Windows 上的特殊限制：NTFS 硬链接 vs. junction/symlink
Windows 的硬链接（由 mklink /H 创建）在 NTFS 上支持 equivalent；但 junction point（mklink /J）和 symbolic link（mklink）不共享 inode，equivalent 对它们的行为与符号链接一致：只在路径字符串完全相同时返回 true。
- 确认是硬链接：用 PowerShell 查
Get-ChildItem -Path "path" | Select-Object LinkType，输出应为HardLink - 管理员权限不是必须的，但创建硬链接需权限；判断等价性本身不需要特权
- Windows 的
std::filesystem::equivalent底层调用GetFileInformationByHandle，对硬链接能正确比对dwVolumeSerialNumber+nFileIndexHigh/nFileIndexLow
跨平台代码里最容易忽略的，是没区分硬链接和符号链接的创建方式 —— 尤其在 CI 环境中，Linux 默认允许硬链接，Windows 默认禁用（需开发者模式或管理员开启），导致测试路径根本建不出硬链接，equivalent 测试就跑在假数据上。
