std::filesystem::equivalent 返回 false 即使路径指向同一文件，因其不自动规范化路径，需先用 canonical 或 absolute 处理；跨文件系统、符号链接、Windows UNC 等场景易失败，且有性能开销。
std::filesystem::equivalent 会返回 false 即使两个路径指向同一文件
这是最常踩的坑：你用 std::filesystem::equivalent 比较两个路径（比如 "./file.txt" 和 "/home/user/dir/file.txt"），结果却返回 false，哪怕它们确实指向同一个 inode。根本原因是该函数不自动做路径规范化——它直接调用底层系统 API（如 Linux 的 stat() 对比 st_dev 和 st_ino），而路径未归一化时，stat() 可能因符号链接、相对路径或挂载点差异失败。
实操建议：
- 务必先用
std::filesystem::canonical或std::filesystem::absolute将两个路径转为绝对且解析后的形式，再传给equivalent - 如果任一路径不存在，
equivalent会抛出std::filesystem::filesystem_error，必须捕获处理 - 跨文件系统挂载点（如 bind mount、NFS）可能让
st_dev不同，此时即使物理文件相同，equivalent也返回false
等价性判断前必须处理符号链接和相对路径
equivalent 不展开符号链接——它对比的是最终目标的文件系统元数据，但前提是路径本身能成功解析到目标。例如 "link.txt" 是个软链，若你没用 canonical，而直接拿 "link.txt" 和 "target.txt" 去比，大概率失败，因为前者 stat 得到的是链接自身的 inode（不是目标的）。
正确做法：
立即学习“C++免费学习笔记（深入）”；
- 对每个路径调用
std::filesystem::canonical(path)，它会递归解析所有符号链接，并返回规范化的绝对路径 - 若只需处理相对路径而无需解链，可用
std::filesystem::absolute(path)，但它不处理符号链接，慎用于含..或软链的场景 - 注意
canonical在路径不存在时也会抛异常，建议先用exists()预检，或统一 try/catch
Windows 下要注意驱动器大小写和网络路径
Windows 文件系统默认不区分大小写，但 equivalent 底层仍依赖 GetFileInformationByHandle，其行为受卷标、重解析点（如符号链接、目录交接点）影响。常见问题包括：
-
"C:\file.txt"和"c:\FILE.TXT"在大多数情况下会被判为等价，但若涉及不同卷挂载或 OneDrive 虚拟文件，可能失败 - UNC 路径（如
"\\server\share\file.txt"）与映射驱动器（如"Z:\file.txt"）通常不等价，即使映射到同一共享——因为st_dev在 Windows 上对应卷序列号，而 UNC 和驱动器属于不同“设备” - Windows 的
canonical对 UNC 路径支持有限，某些版本可能抛not_supported异常，需降级用absolute+ 手动标准化（如统一转小写、移除尾部斜杠）
性能开销比想象中大，别在热路径频繁调用
每次调用 equivalent 至少触发两次 stat 系统调用（每个路径一次），而 canonical 更重——它要逐段 stat 并解析符号链接，路径越深、软链越多，耗时越长。在循环里直接对未缓存的字符串路径反复调用，很容易成为瓶颈。
优化建议：
- 把已 canonical 化的
std::filesystem::path缓存起来，后续等价比较复用该对象，避免重复解析 - 如果只是判断“是否为同一文件”，且已知路径合法，可考虑用
std::filesystem::status(path).type()先快速排除类型差异（比如一个是目录一个是文件），减少无效equivalent调用 - 极端性能敏感场景（如构建系统文件去重），改用
std::filesystem::hard_link_count或直接读取st_ino/st_dev（通过std::filesystem::symlink_status获取file_status后访问底层stat结构）更可控，但也更平台相关
真正麻烦的从来不是函数怎么写，而是你忘了它不自动 canonical，以及没意识到跨挂载点或 Windows UNC 这些边界情况会让等价性突然失效。
