std::filesystem::equivalent() 是 C++17 唯一标准、跨平台判断两路径是否指向同一文件的方案，通过系统调用比对 inode 或文件索引，而非仅路径字符串或规范形式；需捕获 filesystem_error 异常，并确保使用绝对路径以避免 CWD 影响。
用 std::filesystem::equivalent() 判断两个路径是否指向同一文件
这是 C++17 标准提供的唯一标准、跨平台的解决方案。它会真正检查两个路径在文件系统层面是否解析为同一个 inode（类 Unix）或等价对象（Windows），而不仅仅是字符串相等或规范后相等。
注意：std::filesystem::equivalent() 会抛出 std::filesystem::filesystem_error 异常（例如路径不存在、无权限访问），必须捕获或声明 noexcept(false)。
try {
bool same = std::filesystem::equivalent("/home/user/file.txt", "/home/user/../user/file.txt");
if (same) {
// 确实指向同一文件
}
} catch (const std::filesystem::filesystem_error& e) {
// 处理路径无效、不可访问等情况
}
为什么不能只用 std::filesystem::canonical() 比较？
std::filesystem::canonical() 把路径转成绝对且无符号链接的规范形式，但有两个关键缺陷：
- 若任一路径包含悬空符号链接，
canonical()直接抛异常，无法继续判断 - 即使成功，它只做路径归一化，不验证底层文件实体是否相同（比如硬链接指向同一 inode，但 canonical 后路径不同）
- 性能开销更大：需逐级解析目录、读取 symlink、检查权限等
所以，equivalent() 是语义正确且更健壮的选择 —— 它内部调用的是 stat()/GetFileInformationByHandle() 级别系统调用，直接比对设备号+inode（Unix）或 volume serial + file index（Windows）。
常见错误：传入相对路径未处理当前工作目录影响
std::filesystem::equivalent() 对相对路径的解析依赖当前工作目录（CWD）。如果程序运行时 CWD 变化，结果可能意外失败或误判。
让 Windows 桌面程序在开机时静默自启并隐藏到系统托盘。特别适用于 Flutter、Electron 等无视 VBS/ProcessStartInfo 窗口样式、难以隐藏的顽固应用。提供「VBS 启动器 + Python ctypes/Win32 API」的隐藏窗口方案，可稳定把窗口收进托盘且不闪控制台。
- 确保传入的路径是绝对路径，或显式转换：
std::filesystem::absolute(p) - 避免在多线程环境中调用
chdir()，否则 CWD 变更会影响后续equivalent()行为 - 测试时不要只用
"./file"和"file"这类看似等价的相对路径 —— 它们在equivalent()下通常返回false，因为解析起点可能不同
Windows 上的特殊情况：重解析点与卷挂载点
Windows 的 NTFS 重解析点（如符号链接、目录交接点、卷挂载点）会让 equivalent() 行为更复杂：
- 符号链接默认被跟随（followed），即比较目标文件，不是链接本身
- 若想比较链接文件自身（而非其目标），需先用
std::filesystem::is_symlink()判断，再用std::filesystem::read_symlink()获取路径，但此时已不适用equivalent() - 卷挂载点（如
C:\mount\ → D:\data\）会被视为不同卷，即使物理磁盘相同，equivalent()也返回false
这意味着：在 Windows 上，equivalent() 的“同一文件”定义严格依赖于操作系统对文件系统对象的唯一标识方式，和 Unix 一致，但表现受 NTFS 特性影响更大。
真正容易被忽略的是异常边界 —— 很多人只写 equivalent(a, b) 却没包 try/catch，导致路径不存在时整个函数崩溃；还有人把未检查的相对路径直接传入，结果因 CWD 不一致得到非预期 false。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
