直接读取 /proc/mounts 文件即可，无需系统调用或库函数封装
在Linux系统中，如何快速查看当前所有磁盘挂载点？最直接高效的方法就是访问 /proc/mounts 文件。这个文件由内核动态生成，以标准化的文本格式实时呈现系统挂载状态。使用C++标准文件流读取该文件，相比调用封装好的库函数更为轻量且可控，还能避免引入
许多开发者在自行解析时，常担心字段内可能包含空格。实际上无需过度顾虑。虽然第4列的挂载选项（例如 relatime,strictatime）可能包含逗号，但绝不会包含空格。而第3列的文件系统类型，以及第5、6列，始终是独立的单词。因此，使用空格作为分隔符来切分前四个字段是完全安全可靠的。
使用 std::getline + std::istringstream 解析比手动 strtok 更稳健
为何推荐这套标准库组合？因为 /proc/mounts 每行的字段间由多个连续空格分隔，而非制表符。更重要的是，第4列内部使用逗号分隔。手动编写分割循环容易出错，而标准流中的 >> 提取操作符具备天然优势：它能自动跳过所有多余的空白字符，完美适配这种格式。
以下是核心实现代码：
std::ifstream mounts("/proc/mounts");
std::string line;
while (std::getline(mounts, line)) {
if (line.empty() || line[0] == '#') continue;
std::istringstream iss(line);
std::string dev, mp, fstype, opts;
if (iss >> dev >> mp >> fstype >> opts) {
// 此时 mp 即为挂载点路径，例如 "/home" 或 "/"
std::cout << "Mount point: " << mp << "\n";
}
}
解析过程中有几个关键细节需要注意：
- 避免使用
strtok：它会破坏原始字符串，且处理多个连续空格时不够健壮。 - 不推荐正则表达式：解析此类小文件无需复杂工具。此外，C++11的
- 后续字段处理：若需进一步分析
opts字段（例如检查是否包含noexec选项），可再使用一次std::stringstream按逗号进行分割。
注意权限与挂载命名空间隔离问题
读取 /proc/mounts 本身无需特殊权限，普通用户即可访问。但必须理解一个核心概念：你看到的内容取决于进程所在的“观察点”，即挂载命名空间（mount namespace）。
这意味着什么？例如，在Docker容器内运行此代码，默认只能看到容器自身的挂载点（如 /proc、/dev/pts），而无法看到宿主机上的 /home 或 /data 目录。这是Linux容器实现资源隔离的基础机制之一。
- 若需查看宿主机的全局视图，则需要在特权（privileged）容器中运行，或通过特殊方式挂载宿主机的
/proc文件系统（通常不建议）。 - 挂载新设备需要root权限，但仅读取现有挂载信息则不受限制。
对比 getmntent()：何时应选用C标准库接口
那么，何时应考虑使用 getmntent() 这类C库函数？主要场景是需要更明确的语义或获取更底层字段时。例如，过滤所有 ext4 或 nfs 类型的文件系统，或需要访问 mnt_freq、mnt_passno 等字段时，getmntent() 提供的结构体更为清晰。
但使用时需注意：返回的结构体中字段为裸指针，必须谨慎管理其生命周期。此外，在musl libc等环境下，其行为可能与glibc存在差异。
- 配套函数调用：使用
getmntent()必须配对调用setmntent()和endmntent()，否则可能导致文件句柄泄漏。 - 路径无关性：其优势在于可直接通过
getmntent("/proc/mounts", "r")读取，无需在代码中硬编码路径字符串。 - 纯C++项目：若项目希望保持纯粹的C++风格，避免C风格API，那么坚持使用
std::ifstream的方案完全可行。两者在性能上无明显差异，更多是代码风格的选择。
最后，分享一个实战中极易忽略的排查技巧：当读取的挂载信息不符合预期时，切勿仅纠结于解析逻辑。首先应确认当前进程所处的挂载命名空间。在systemd服务、Podman容器或chroot环境中，结果可能截然不同。通过执行 ls /proc/self/ns/mnt 命令，可快速验证自身“视角”是否与宿主机一致。许多问题根源正在于此。
