c++oding="utf-8" ?>
std::filesystem::equivalent 在硬链接判断中不可靠。windows 默认不支持，linux/macos 受文件系统、权限和挂载点限制，并非同源必返回 true；跨平台应改用文件大小加内容哈希等业务层方案。
std::filesystem::equivalent 在硬链接判断中是否可靠
不可靠。它在 Windows 上默认不支持硬链接等价性判断，Linux/macOS 虽能工作，但行为受文件系统和权限限制，并非“同源即返回 true”。std::filesystem::equivalent 检查的是路径是否指向同一个文件系统对象（inode 或其等价抽象），但它的实现依赖底层 OS API：Windows 用 GetFileInformationByHandle，仅当两个句柄来自同一打开操作或显式重复句柄时才可能判定等价；而硬链接在 NTFS 上共享 inode-like 标识，但标准库实现通常不触发该路径——多数 libc++/libstdc++ 在 Windows 下对不同路径的硬链接总是返回 false。
Linux/macOS 下使用 equivalent 判断硬链接的实际条件
需同时满足以下条件才能得到预期结果：
-
std::filesystem::equivalent才会比较底层 inode 号（通过stat()的st_dev+st_ino） - 两个路径必须可访问且不被符号链接干扰（
equivalent不自动解析 symlink，传入 symlink 路径时行为未定义） - 调用进程需有读取两个路径 metadata 的权限，否则抛出
std::filesystem::filesystem_error - 不能跨挂载点（即使硬链接存在，跨设备时
st_dev不同，必然返回false）
示例（Linux）：
std::error_code ec;
bool same = std::filesystem::equivalent("/tmp/a", "/tmp/b", ec);
if (ec) {
// 权限不足或路径不存在，不要忽略 ec
}
Windows 上硬链接等价性必须绕过 equivalent
Windows 硬链接（mklink /H 创建）共享同一 MFT 记录，但 std::filesystem::equivalent 在 MSVC STL 和 libstdc++ 中均不利用此信息。实测表明，即使两个硬链接位于同一卷、由同一用户创建，equivalent 仍返回 false。替代方案只有：
- 手动调用
GetFileInformationByHandle获取BY_HANDLE_FILE_INFORMATION，比对dwVolumeSerialNumber+nFileIndexHigh/nFileIndexLow - 用
std::filesystem::status提取file_status.type()和permissions()辅助排除，但无法确认等价 - 避免依赖等价判断，改用业务层唯一标识（如文件内容哈希 + size）
跨平台硬链接同源判断的务实做法
没有零成本、标准库直达的方案。最简健壮路径是：
- 先用
std::filesystem::is_regular_file排除非普通文件 - 在 Linux/macOS 调用
equivalent，捕获并忽略ec错误；在 Windows 直接跳过，视为“未知” - 若需确定性判断，统一走内容指纹：
std::filesystem::file_size相同再计算 SHA-256（小文件可全读，大文件读头尾+中间块） - 注意：硬链接与副本无法仅靠 size 区分，但多数场景下 size + hash 已足够替代 “同源” 语义
真正棘手的不是代码怎么写，而是接受「C++ 标准库不承诺硬链接感知」这个事实——equivalent 的跨平台语义本质是“逻辑等价”，而非“物理同源”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
