C++如何获取硬盘分区的详细挂载点信息与剩余空间 _ filesystem库【实战】

提到 std::filesystem::space，很多 C++ 开发者首先想到的就是拿它来查询磁盘空间。但这个 API 真的有看起来那么能干吗？

先说几个核心判断：它只返回 capacity、free、a vailable 三个数字，至于这个路径属于哪个挂载点、文件系统是什么类型、能不能写——统统不告诉你。更坑的是，如果你传进去一个符号链接，它查的是链接指向的目标位置的文件系统，而不是链接本身所在的分区。所以，在需要精确管理存储资源的场景里，这个 API 的信息量根本不够用。

从结构上看，space_info 就三个字段，没有设备名、没有挂载路径、也没有文件系统类型。跨平台行为虽然一致，但信息严重不足；Windows 下甚至可能把 NTFS 卷和 ReFS 卷都统报为同一抽象“空间”，你完全无法区分底层挂载关系。而且，如果路径不存在或权限不足，它会抛 filesystem_error，你必须显式捕获，否则程序就直接挂了。

那么，在 Windows 上想要枚举所有挂载点并拿到完整的空间信息，该怎么办？得绕开标准库，直接调用 Win32 API。常见组合拳是：GetLogicalDrives 获取有盘符的驱动器位掩码，然后对每个盘符调用 GetDiskFreeSpaceEx。需要注意的是，GetDiskFreeSpaceEx 返回的三个值里，第三个是 total_free，它和 free 并不等价——因为系统会保留一部分空间。要获取卷标和文件系统类型（比如到底是不是 NTFS），还得补上 GetVolumeInformation，提前分配好 MAX_PATH 大小的缓冲区。千万别试图用 directory_iterator("C:/") 去猜挂载点，它遍历的是目录内容，不是卷列表；也别硬编码 "C:"、"D:" 字符串，Windows 支持把卷挂载到任意空目录（比如 C:\mnt\data），这时它没有盘符，传统方法会漏掉。要捕捉这种场景，得用 FindFirstVolume/FindNextVolume 配合 GetVolumePathNamesForVolumeName。

Linux 和 macOS 下的玩法又不一样了。读 /proc/mounts（Linux）或 getmntinfo（macOS）只是拿到了挂载点列表，真正的空间数据必须调用 statvfs。struct statvfs 里的字段需要手动换算：f_blocks * f_frsize 是总空间，f_ba vail 是非 root 用户可用空间，而 f_bfree 是 root 可用空间（通常多 5% 的保留块）。计算容量时，必须用 f_frsize，而不是 f_bsize（那个是 I/O 块大小）。

在 Linux 上遍历 /proc/mounts 时，记得过滤掉 proc、sysfs、devtmpfs 这些虚拟文件系统，否则 statvfs 会返回 0 或 -1。macOS 那边，/etc/fstab 只管静态配置，运行时动态挂载的外接硬盘、APFS 加密卷都不会出现在里面，所以必须用 getmntinfo。另外，statvfs 对 NFS 挂载可能阻塞甚至超时，生产环境里建议用 alarm() 或者走线程加超时控制，别让一个调用卡死整个主逻辑。

最后，如果把这一切封装成跨平台接口，真正的坑往往不在 API 选择上，而在语义对齐、错误容忍和路径归一化这几个细节。Windows 下 "C:" 和 "C:\" 在 GetDiskFreeSpaceEx 中的行为不同——前者可能失败，后者才稳定；Linux 下 statvfs("/home") 和 statvfs("/home/") 结果一样，但路径末尾缺了斜杠可能导致 realpath() 失败，从而找不到挂载点。有些 Linux 文件系统（比如 overlayfs、btrfs subvolume）会在 /proc/mounts 里出现多次，但 statvfs 返回的是底层块设备的空间，不是子卷的配额——如果你需要子卷级别的空间数据，得调 btrfs filesystem usage 或解析 /sys/fs/btrfs/*/allocations，标准库这层完全不覆盖。

权限问题也是重灾区。普通用户在 Linux 上对某些挂载点（比如 root-squashed NFS）调 statvfs，会返回 -1 并设 errno=EPERM，此时应该降级为跳过，而不是抛异常；Windows 上碰到 BitLocker 加密卷未解锁的情况，GetDiskFreeSpaceEx 返回 FALSE，GetLastError() 给出 ERROR_ACCESS_DENIED，也得静默处理。

挂载点识别和空间统计从来不是纯算法问题，而是操作系统接口契约的理解问题。别指望一个 std::filesystem 调用能横跨 Win、macOS、Linux 给出一致且完整的答案。