linux下判断路径是否位于nvme设备的可靠方法是：先用stat -c "%d"获取设备主从号，再通过/sys/class/block/定位真实设备名，最后用udevadm info确认id_bus=nvme；lsblk -d -o tran=nvme为硬指标，而df -t或文件系统类型等均不可靠。
Linux下用stat和udevadm查设备类型
直接看路径挂载点对应的底层块设备是否属于NVMe，比猜文件系统或厂商名靠谱得多。核心思路是：先用stat -c "%d" /path/to/file拿到设备主从号（major:minor），再查这个设备在/sys/class/block/下的真实名字，最后通过udevadm info --name=/dev/nvme0n1p1 --query=property确认ID_BUS是否为nvme。
-
stat -c "%t:%T" /path/to/file输出十六进制的主从号（如ca:01），转成十进制后对应/sys/dev/block/<major>:<minor></minor></major>软链接目标 - 别依赖
df -T输出的Filesystem列——它可能显示/dev/sda1，但实际是NVMe设备被内核识别为SCSI兼容模式（比如某些老BIOS或虚拟化环境） -
lsblk -d -o NAME,ROTA,TYPE,TRAN里TRAN=nvme才是硬指标；ROTA=0只是旋转介质提示，SSD和NVMe都满足，不能单独作为判断依据
Windows上用GetDriveType和WMI组合验证
GetDriveType只能区分是否为固定磁盘，无法区分SATA SSD和NVMe。真正有效的是WMI查询：SELECT InterfaceType FROM Win32_DiskDrive WHERE DeviceID LIKE '%PHYSICALDRIVE0%'，其中InterfaceType返回NVME才可信。
- 必须用
DeviceID关联逻辑卷和物理磁盘——先调GetVolumePathNamesForVolumeName拿到卷GUID，再用Win32_VolumeToDiskDrive关联到Win32_DiskDrive - 注意权限：WMI查询在受限账户下可能失败，建议用
CoInitializeSecurity设置适当安全上下文 - 别信
Win32_PhysicalMemory或Win32_SSD类——后者根本不存在，前者只报告内存
C++跨平台封装的关键陷阱
没有标准库函数能直接返回“此路径是否在NVMe上”，所有方案都要绕道系统API。最易出错的是路径解析环节：C++的std::filesystem::canonical可能因符号链接、挂载点嵌套而指向错误设备。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- Linux下务必用
realpath()而非canonical()，后者不解析挂载点边界；对/proc/mounts逐行匹配时，要按路径长度降序排序，避免/mnt/data匹配到/mnt - Windows下
\?前缀路径传给WMI时需先剥离，否则DeviceID查询失败 - 缓存设备信息：频繁查同一路径时，把
(device_id → is_nvme)映射存起来，避免重复WMI或sysfs读取——NVMe识别本身不耗时，但WMI初始化开销大
为什么ioctl和SMART数据不推荐
有人想用HDIO_GET_IDENTITY或nvme-cli的identify命令查设备能力，但这要求有读取块设备权限，且无法从任意文件路径反推设备节点——你得先知道它挂在哪个/dev/nvme*上，而这正是你要解决的问题。
-
smartctl -i /dev/nvme0n1输出里的Device Model含“NVMe”字样？不可靠——有些OEM固件会伪造字符串，或根本不填 - 用户态程序几乎不可能获得
/dev/nvme0的O_RDONLY句柄，尤其当该设备被其他进程独占时 - 即使成功，SMART识别也只说明设备是NVMe，不等于你访问的文件路径一定落在其上——比如该NVMe分了多个分区，而你的路径在另一个挂载的SATA盘上
真正可靠的路径到NVMe判定，永远始于挂载点映射，终于设备总线类型。中间任何跳过设备层的猜测，都会在双硬盘、LVM、btrfs subvolume或WSL2场景下失效。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
