Linux 下应直接读取 /proc/mounts 获取挂载点，因其轻量、可靠、格式固定；Windows 下需结合 GetLogicalDrives() 与 GetDriveType() 判断真实可用驱动器，跨平台应分设接口避免语义混淆。
Linux 下用 /proc/mounts 解析挂载点最直接
Linux 没有“驱动器盘符”概念，但所有已挂载的文件系统（含磁盘、分区、网络存储等）都记录在 /proc/mounts 中。读取它比调用系统命令更轻量、更可靠，且无需 fork 或解析 shell 输出。
注意：该文件内容与 mount 命令输出基本一致，但格式固定、无颜色/缩进干扰，适合程序解析。
- 每行格式为：
设备名 挂载点 文件系统类型 选项 dump pass，前两项最关键 - 跳过以
none、sysfs、proc、devtmpfs等虚拟文件系统开头的行，它们不是物理磁盘 -
device字段可能是设备路径（如/dev/sda1）、UUID（UUID=...）或 LABEL（LABEL=...），需按需提取真实块设备 - 用
std::ifstream逐行读取，std::string::find_first_of(' ')分割字段更稳妥，避免空格导致的 split 错误
Windows 下必须用 GetLogicalDrives() + GetDriveType()
Windows 的“驱动器”是盘符抽象（C:\、D:\），GetLogicalDrives() 返回一个位掩码，每个 bit 对应 A–Z 盘符是否被定义；但它不区分是否真正挂载或可访问——比如光驱没放盘、网络驱动器断连时，盘符仍存在。
所以必须配合 GetDriveType(L"X:") 过滤出实际可用的本地磁盘、可移动磁盘或固定磁盘（返回值为 DRIVE_FIXED、DRIVE_REMOVABLE 或 DRIVE_FIXED）。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 不要只依赖
GetLogicalDrives()就认为所有 bit=1 的盘符都“已挂载” - 调用
GetDriveType()前必须确保路径末尾有反斜杠（L"C:\"），否则可能返回DRIVE_NO_ROOT_DIR - 对 NTFS 卷，若需获取对应物理设备（如
\.PhysicalDrive0），得进一步查QueryDosDevice或 WMI，这已超出“已挂载”范畴
跨平台封装时别硬套统一接口
试图用同一套 C++ 接口在 Linux 和 Windows 上返回“驱动器列表”，容易引发语义混淆：Linux 返回的是挂载点路径（/home、/mnt/data），Windows 返回的是盘符（C:\）。强行合并成一个 std::vector<:string></:string> 会让调用方难以判断含义。
- 推荐分两个函数：
get_mounted_filesystems()（Linux 风格，返回挂载路径 + 设备）和get_available_drives()（Windows 风格，返回盘符 + 类型） - 若必须统一，返回结构体而非字符串，例如：
struct MountInfo { std::string path; std::string device; std::string fs_type; bool is_physical; }; - 别在 Linux 上尝试模拟盘符逻辑（比如把
/dev/sdb1映射成Z:\）——这既无标准，也破坏用户对路径的预期
常见错误：把 df -h 输出当唯一依据
很多人习惯用 popen("df -h") 解析，但这有几个硬伤：
-
df默认只显示“有空间”的挂载点，tmpfs、devtmpfs等内存文件系统常被过滤掉，而它们确实在/proc/mounts中 - 不同 locale 下单位（G / GB）、小数点符号（. / ,）可能变化，正则解析易崩
- 权限问题：非 root 用户执行
df可能看不到某些挂载（如 NFS），但读/proc/mounts通常没问题 - 性能差：每次调用都要 fork+exec，而
/proc/mounts是内核提供的零拷贝伪文件
除非你明确需要人类可读的空间统计，否则绕过 df 直接读 /proc/mounts 或调用 getmntent() 是更干净的选择。
