std::filesystem::equivalent 是 C++17 起唯一标准、跨平台、语义正确的物理等价判断方式，底层调用系统 API 比较 inode 或文件对象，自动解析符号链接，不依赖路径字符串比较。
std::filesystem::equivalent 是唯一靠谱的判断方式
用 std::filesystem::equivalent 是 C++17 起唯一标准、跨平台、语义正确的方案。它底层调用系统 API（如 Windows 的 GetFileInformationByHandle，Linux/macOS 的 stat 比较 st_dev 和 st_ino），真正判断是否指向同一 inode 或文件对象，不是字符串比较，也不是简单解析符号链接。
常见错误是自己拼接路径再字符串比对，或只调用 std::filesystem::canonical 后比较结果——这两者都可能误判：符号链接嵌套、挂载点、硬链接、大小写敏感文件系统（如 macOS APFS 默认不区分大小写）都会导致出错。
-
std::filesystem::equivalent自动处理符号链接解析（默认 fully resolve），无需手动canonical - 若任一路径不存在，抛出
std::filesystem::filesystem_error，必须捕获 - 路径不必是绝对路径，但相对路径按当前工作目录解析，容易隐式依赖环境
等价性判断失败的典型报错和原因
最常遇到的是 std::filesystem::filesystem_error: No such file or directory。这不是“功能失效”，而是明确告诉你：至少一个路径无法访问（权限不足、路径不存在、跨网络断开等）。
另一个隐蔽问题是权限：即使路径存在，若进程对某个中间目录缺少执行（x）权限（Linux/macOS）或遍历权限（Windows），equivalent 仍会失败——它需要完整路径可访问才能获取元数据。
立即学习“C++免费学习笔记（深入）”；
- 检查路径是否存在：先用
std::filesystem::exists预检（但注意竞态条件） - 避免在无权目录下构造路径，比如
/proc/self/fd/3这类伪路径，equivalent不支持 - Windows 上重解析点（如目录交接点）会被正确识别为等价，但软链接（mklink /D）需确保目标可访问
与 std::filesystem::canonical 的关键区别
std::filesystem::canonical 只做路径规范化：解析 .、..、符号链接，返回一个“看起来一样”的绝对路径字符串。但它不验证目标是否真实存在，也不保证两个 canonical 结果相等就代表物理等价。
例如：/home/user/dir 和 /home/user/../user/dir canonical 后相同；但若前者是硬链接，后者是另一硬链接，它们指向不同 inode —— canonical 无法发现，而 equivalent 可以。
-
canonical可能抛异常（路径不存在时），也可能返回看似合理但实际无效的路径（如 dangling symlink） -
equivalent不返回路径，只返回bool，语义更干净，也更重（要真正 stat 两次） - 性能上，
equivalent是两次系统调用，canonical可能多次读目录，但实际差异不大；别为了省一次 syscall 放弃语义正确性
实际使用时的边界场景处理
真实项目里最容易翻车的是跨设备、跨挂载点、以及空路径或根路径。比如 equivalent("/mnt/usb/file.txt", "/home/user/file.txt") 必然返回 false（不同 st_dev），但这不是 bug，是设计如此。
还有 Windows 特殊情况：NTFS 卷上的硬链接、符号链接、目录交接点，equivalent 全部支持；但 FAT32/UFD 不支持硬链接，此时所有链接都是副本，equivalent 自然返回 false。
- 不要假设
equivalent(a, b)和equivalent(b, a)行为不同——它是对称的 - 传入空字符串或非法字符（如 Windows 的
<code>、<code>>）会导致std::filesystem::path构造失败，提前崩溃 - 若需容忍“逻辑等价”（如忽略大小写），得自己封装：先
equivalent，失败后再尝试转换为小写路径并比较，但要注意这已脱离物理等价定义
equivalent 就是为此而生，别绕路。 
