std::filesystem::equivalent 能判断硬链接同源，因为它在 POSIX 系统上比较 inode、在 Windows 上比较文件 ID 与卷序列号，而硬链接共享同一 inode 或文件 ID，故指向同一实体即返回 true。
std::filesystem::equivalent 为什么能判断硬链接同源
std::filesystem::equivalent 的底层逻辑是通过比较两个路径对应的 inode（在 POSIX 系统上）或文件 ID + 卷序列号（在 Windows 上）来判定是否指向同一文件系统对象。硬链接共享同一个 inode，因此只要两个路径都指向同一硬链接组中的任意成员，equivalent 就返回 true——它不关心路径字符串是否相同，只认底层文件实体。
注意：该函数要求两个路径都存在且可访问，否则抛出 std::filesystem::filesystem_error；它不处理符号链接的递归解析（即默认不跟随 symlink），这点和 std::filesystem::canonical 不同。
调用 equivalent 前必须确保路径有效且不为 dangling symlink
常见错误是传入已删除目标的符号链接、权限不足的目录，或拼写错误的路径，导致抛出异常而非返回 false。硬链接判断本身不失败，但路径预检失败就根本走不到比较逻辑。
- 先用
std::filesystem::exists(path)或std::filesystem::status(path).type() == std::filesystem::file_type::regular做存在性检查 - 避免直接对 symlink 调用
equivalent(a, b)：如果 a 是 symlink 而 b 不是，且你本意是比它们指向的目标，则需先用std::filesystem::read_symlink或std::filesystem::canonical归一化 - 硬链接只能存在于同一文件系统内，跨挂载点的路径即使内容相同也一定返回 false
Linux 下验证硬链接等价性的最小可行代码
以下代码片段假设你已创建了硬链接（例如 ln original.txt link1），并想确认两者等价：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
#include <filesystem>
#include <iostream>
int main() {
try {
bool eq = std::filesystem::equivalent("original.txt", "link1");
std::cout << std::boolalpha << eq << "\n"; // true
} catch (const std::filesystem::filesystem_error& e) {
std::cerr << e.what() << "\n"; // 如 "No such file or directory"
}
}
关键点：equivalent 不修改路径、不解析 symlink、不依赖内容哈希——它就是一次系统调用（stat()）的封装。所以速度快，但前提是路径合法且位于同一设备。
Windows 上要注意 NTFS 硬链接与 reparse point 的区别
Windows 的硬链接（由 mklink /H 创建）确实被 equivalent 正确识别，但要注意：
- 普通快捷方式（.lnk 文件）或符号链接（
mklink无/H）不是硬链接，equivalent对它们默认不跟随，所以两个 .lnk 文件即使指向同一目标也返回 false - 启用开发者模式或管理员权限才能创建硬链接；普通用户调用
CreateHardLink会失败，此时equivalent仍能工作——但它只对真实存在的硬链接生效 - 某些备份工具或 OneDrive 可能将文件转为“重解析点”（reparse point），这类对象不共享 inode，
equivalent会返回 false 即使内容一致
真正容易被忽略的是：equivalent 的行为完全依赖 OS API，C++ 标准不保证跨平台一致性细节——比如 macOS 的 APFS 对硬链接的支持较弱，某些场景下可能 fallback 到内容比较（极少见，但测试时不能只信 Linux 表现）。
