/proc/partitions 是linux中轻量、可靠获取内核已注册块设备分区的方法，需过滤主设备行、虚拟设备（如loop/ram/md）及大小为0的条目，仅保留带数字后缀的真实分区名（如sda1），结果为/dev/sdxn格式。
Linux 下用 /proc/partitions 解析活跃块设备
Linux 没有“活跃磁盘分区”这种内核级概念，但实际需求通常指：已识别、有主设备号、且当前挂载或至少能被内核访问的块设备（如 sda1、nvme0n1p2）。最轻量、最可靠的方式是读取 /proc/partitions —— 它由内核实时维护，无需 root 权限，也不依赖 udev 或 systemd。
关键点在于过滤：跳过主设备行（无数字结尾）、排除 ram/loop/md 等虚拟设备、忽略大小为 0 的条目。示例代码核心逻辑：
#include <fstream>
#include <string>
#include <vector>
#include <sstream>
std::vector<:string> getActivePartitions() {
std::vector<:string> result;
std::ifstream f("/proc/partitions");
std::string line;
while (std::getline(f, line)) {
std::istringstream iss(line);
std::string major, minor, blocks, name;
if (!(iss >> major >> minor >> blocks >> name)) continue;
// 跳过 header 和主设备（name 无数字结尾）
if (name.empty() || std::isdigit(name.back()) == 0) continue;
// 排除 loop/ram/md/nbd 等
if (name.find("loop") == 0 || name.find("ram") == 0 ||
name.find("md") == 0 || name.find("nbd") == 0) continue;
result.push_back("/dev/" + name);
}
return result;
}
</:string></:string></sstream></vector></string></fstream>
注意：/proc/partitions 不反映挂载状态，只反映内核已注册的块设备分区；若需进一步确认是否“活跃”（比如有 I/O），得查 /sys/block/*/stat，但绝大多数场景不需要。
Windows 下用 WMI 查询 Win32_Volume 获取可访问卷
Windows 没有直接对应 Linux 分区的概念，而是以 Win32_Volume 为主——它代表有驱动器号或挂载点的逻辑卷（含 NTFS/FAT/exFAT，不含未分配空间或 RAW 卷）。用 C++ 调 WMI 需链接 comsuppw.lib 并初始化 COM，但关键陷阱不在代码长度，而在权限与结果过滤：
- 必须用管理员权限运行才能看到所有卷（尤其是系统保留、恢复分区）
-
DriveLetter为空 ≠ 不活跃：很多系统卷通过挂载点（MountPoint）访问，需同时检查Capacity> 0 且DriveType== 3（本地磁盘） - WMI 查询可能超时，建议设置
Timeout参数，避免卡死
典型 WQL 查询语句为："SELECT Name, DriveLetter, Capacity FROM Win32_Volume WHERE DriveType=3 AND Capacity > 0"。返回的 Name 是类似 \?\Volume{...}\ 的 GUID 路径，DriveLetter 才是用户熟悉的 C:。别直接用 Win32_DiskPartition —— 它包含未格式化、隐藏、扩展分区等“非活跃”项，噪音极大。
本文档主要讲述的是Android 操作系统的介绍；Android是基于Linux内核的操作系统，是Google公司在2007年11月5日公布的手机操作系统，早期由Google开发，后由开放手持设备联盟（Open Handset Alliance）开发。它采用了软件堆层（software stack，又名以软件叠层）的架构，主要分为三部分。底层Linux内核只提供基本功能；其他的应用软件则由各公司自行开发，部分程序以Java编写。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
跨平台？别硬做，按需选路径
没有标准 C++ API 能跨 Linux/Windows 获取“活跃分区”，强行封装会掩盖差异、引入不可靠判断。比如：
- macOS 用
diskutil list -plist或 IOKit，输出结构和语义与 Linux/Windows 完全不同 - “活跃”定义本身随场景漂移：监控工具要的是有 I/O 的设备；安装程序要的是可写、有文件系统的卷；恢复工具可能需要包含隐藏恢复分区
- 第三方库如
libudev（Linux）或SetupAPI（Windows）虽更底层，但增加依赖、提升编译复杂度，且不解决语义歧义
真正该统一的不是“怎么列分区”，而是上层逻辑：比如“找一个剩余空间 >1GB 的本地可写卷”，那就分别在各平台实现判断，而不是先统一分区列表再过滤。
容易被忽略的边界情况
真实环境中，以下情况常导致你以为“漏了分区”或“多列了设备”：
-
/dev/mapper/*（LVM/加密卷）在/proc/partitions中存在，但名字带短横线或下划线，正则过滤时易误杀 - Windows 中 BitLocker 加密卷若未解锁，
Win32_Volume仍会返回，但Capacity为 0 或访问报错，需额外尝试GetDriveType() - NVMe 设备名如
nvme0n1p1在较老内核（nvme0n1（无 p 后缀），解析时不能硬匹配p\d+ - Docker 或 LXC 容器内读
/proc/partitions看到的是宿主机设备列表，不是容器视角 —— 这不是 bug，是设计如此
与其追求“完整列表”，不如明确你要拿这个列表做什么，然后在对应平台用最窄、最稳的接口打点。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
