结论：std::filesystem::equivalent 在 windows 下无法可靠判断硬链接同源，因其底层调用 getfileinformationbyhandle 前会意外解开硬链接，导致比对目标文件而非链接自身；正确做法是使用 file_flag_open_reparse_point 手动调用 windows api 比较卷序列号与文件索引。
std::filesystem::equivalent 在 Windows 上根本不能判断硬链接
直接说结论：std::filesystem::equivalent 在 Windows 下对硬链接（hard link）总是返回 false，哪怕两个路径确实指向同一文件系统 inode（在 NTFS 中对应同一个 MFT 记录）。这是因为 Windows 实现依赖于 GetFileInformationByHandle 获取的 dwVolumeSerialNumber + nFileIndexHigh/nFileIndexLow，而硬链接共享这些值——但标准库实现（如 MSVC 19.3x+）在调用前会先做路径规范化和符号链接解析，**意外解开了硬链接**，导致最终比对的是“目标文件”而非“链接自身”的索引信息。
常见错误现象：
– Linux/macOS 下 equivalent("a.txt", "b.txt")（二者为硬链接）返回 true；
– 同样操作在 Windows 下返回 false，即使 fs::status("a.txt").type() == fs::file_type::regular 且 fs::hard_link_count("a.txt") > 1。
- 不要依赖
equivalent做跨平台硬链接检测，它不是为此设计的 - Windows 下硬链接与符号链接（symlink）行为差异极大，
equivalent对 symlink 是能正常工作的 - 若仅需 Linux/macOS，可继续用；但一旦要支持 Windows，就得绕开
Windows 下必须用 GetFileInformationByHandle 手动比对
真正可靠的方案是跳过 std::filesystem，直接调用 Windows API 获取底层文件标识符并比对。关键点在于：必须以 FILE_FLAG_OPEN_REPARSE_POINT 打开句柄，否则硬链接会被自动解析到目标，失去“同源性”判断依据。
实操建议：
- 用
CreateFileW分别打开两个路径，flag 必须含FILE_FLAG_OPEN_REPARSE_POINT | FILE_FLAG_BACKUP_SEMANTICS - 调用
GetFileInformationByHandle，比对返回的dwVolumeSerialNumber、nFileIndexHigh、nFileIndexLow三者是否完全一致 - 记得关闭句柄（
CloseHandle），避免资源泄漏 - Linux/macOS 下可 fallback 到
stat.st_dev == stat.st_dev && stat.st_ino == stat.st_ino
示例片段（Windows 专用）：
BY_HANDLE_FILE_INFORMATION info1 = {}, info2 = {};
HANDLE h1 = CreateFileW(L"a.txt", 0, FILE_SHARE_READ|FILE_SHARE_WRITE,
nullptr, OPEN_EXISTING, FILE_FLAG_OPEN_REPARSE_POINT|FILE_FLAG_BACKUP_SEMANTICS, nullptr);
GetFileInformationByHandle(h1, &info1);
// ... 同理处理 h2 ...
bool same = (info1.dwVolumeSerialNumber == info2.dwVolumeSerialNumber) &&
(info1.nFileIndexHigh == info2.nFileIndexHigh) &&
(info1.nFileIndexLow == info2.nFileIndexLow);
std::filesystem::hard_link_count 不等于 equivalent 的替代品
hard_link_count 只告诉你“这个文件被几个硬链接引用”，不告诉你“这两个路径是否互为硬链接”。比如 a.txt 和 c.txt 可能都链接到同一 inode，但 a.txt 和 c.txt 之间并无直接链接关系——它们只是“同源”，不是“互指”。
使用场景注意：
- 想确认某路径是否是硬链接集合的一员？查
hard_link_count(path) > 1即可 - 想确认
p1和p2是否指向完全相同的文件系统对象（即等价于硬链接关系）？hard_link_count无法回答，必须走底层比对 - Linux 下可用
stat(p1, &s1), stat(p2, &s2)后比较s1.st_dev == s2.st_dev && s1.st_ino == s2.st_ino，这是 POSIX 标准做法
跨平台封装时最容易忽略的权限与符号链接干扰
实际部署中，最常踩的坑不是逻辑错，而是权限和路径解析干扰了底层判断：
- Windows 上非管理员调用
CreateFileW打开某些路径（如系统目录下硬链接）会失败，需捕获ERROR_ACCESS_DENIED并降级处理 - 如果路径包含符号链接（symlink），
equivalent会自动跟随，但硬链接检测不应跟随——所以手动比对前，要用fs::canonical或fs::weakly_canonical预处理？错。应保持原始路径，只开FILE_FLAG_OPEN_REPARSE_POINT来抑制 symlink 解析 - Linux 下
stat对 symlink 默认不跟随，符合需求；但若路径本身是 dangling symlink，stat失败，需提前用fs::is_symlink排查
复杂点在于：硬链接检测不是纯算法问题，它强依赖 OS 层对“路径→文件对象”的绑定语义。Windows 和 POSIX 的设计哲学不同，强行统一抽象只会掩盖差异，不如分治处理。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
