windows下判断两路径是否同分区，应调用getvolumepathname将路径归一化为卷根路径（如"c:"），再字符串比较；不可仅比盘符大小写或路径前缀，因挂载点和符号链接会使前者失效。
Windows下用GetVolumePathName判断分区是否相同
在Windows上，GetVolumePathName 是最直接可靠的方式：它能把任意路径（如 "C:\foo\bar.txt" 或 "D:\data\file.dat"）归一化为对应卷的根路径（如 "C:\" 或 "D:\"），再比较这两个根路径字符串是否相等即可。
注意：不能只比盘符字母（比如 'C' 和 'c'），也不能依赖 GetDriveType —— 它只告诉你是不是固定磁盘，不解决“同一卷”问题；更不能靠解析路径前缀，因为挂载点（如 "C:\mnt\disk2\" 挂载的是另一个物理卷）会让前缀失效。
- 调用前确保路径存在且可访问，否则
GetVolumePathName返回 0，GetLastError()可能是ERROR_PATH_NOT_FOUND - 返回的卷路径末尾带反斜杠（如
"C:\"），建议用CompareStringOrdinal或转小写后比较，避免大小写干扰 - 对符号链接或重解析点，该函数自动解析到底层卷，行为符合预期
Linux/macOS用stat.st_dev判断设备号是否一致
POSIX系统中，每个挂载点对应一个独立的文件系统设备（device ID）。通过 stat() 获取两个路径的 st_dev 字段，值相等即说明在同一个挂载的文件系统（即同一分区）上。
关键点：必须用 stat() 而不是 lstat()，否则遇到符号链接会返回链接自身所在设备，而非目标文件所在设备；且路径需真实存在，否则 stat() 失败返回 -1。
-
st_dev是dev_t类型，不同平台宽度可能不同（常见为 16/32 位），应直接用==比较，不要转成int截断 - 若路径跨 bind mount 或 overlayfs，
st_dev仍反映底层块设备，但语义上是否算“同一分区”取决于你的定义——多数场景下按设备号判等是合理选择 - 注意 NFS 等网络文件系统也返回有效
st_dev，但值仅在本机有意义；跨主机比较无意义
跨平台封装时别忽略权限和路径规范
实际写工具函数时，最容易出错的不是算法逻辑，而是路径预处理和错误处理。比如 Windows 路径含 UNC 前缀（"\\server\share\path"），GetVolumePathName 不支持，得先映射成本地驱动器或改用 WNetGetUniversalName；Linux 下相对路径若未从当前目录解析，stat() 可能失败。
- 统一用
std::filesystem::absolute()归一化路径，避免相对路径干扰（注意 C++17 标准库在某些旧编译器上absolute对 UNC 支持不全） - 检查
stat()或GetVolumePathName()返回值，不要假设成功；对无效路径，明确返回 false 或抛异常，而非静默 fallback - Windows 上若路径指向已断开的网络驱动器，
GetVolumePathName可能卡住或超时，建议设短超时或提前用GetDriveType快速过滤掉DRIVE_NO_ROOT_DIR
为什么不能只看盘符或挂载点路径
盘符只是 Windows 的逻辑映射，一个物理磁盘可以有多个盘符（通过 subst 或磁盘管理），多个物理磁盘也可以共用一个盘符（通过目录挂载）；Linux 挂载点路径（如 /mnt/data）只是入口，底层设备可能随时被 umount/re-mount 到别处。真正唯一标识分区的是 Windows 的卷 GUID（GetVolumeNameForVolumeMountPoint 返回值）或 Linux 的 st_dev。
如果你需要更高精度（比如区分同一块 SSD 上的不同分区），Windows 应用 GetVolumeNameForVolumeMountPoint 获取卷 GUID 字符串（形如 "\\?\Volume{a1b2c3d4-...}\" ），Linux 可读 /proc/mounts 或用 statfs() 获取 f_fsid，但绝大多数场景，盘符归一化或 st_dev 已足够。
真正麻烦的是容器、WSL、FUSE 文件系统这些抽象层——它们让“分区”边界变得模糊，这时候得根据具体运行环境重新定义“同一分区”的语义，而不是硬套系统 API。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
