GetDriveType是Windows API中用于判断磁盘类型的函数，返回DRIVE_REMOVABLE（2）表示可移动磁盘，但部分USB SSD可能被识别为DRIVE_FIXED；需传入带尾随反斜杠的根路径如"F:\"，否则返回DRIVE_NO_ROOT_DIR。
Windows下用 GetDriveType 判断是否为可移动磁盘
直接调用 Windows API GetDriveType 是最可靠的方式。它不依赖路径是否存在或是否有读写权限，只看驱动器类型。传入根路径（如 "F:\"）即可，非根路径会先自动解析到对应驱动器。
- 必须以驱动器根目录形式传入，例如
"D:\"，传"D:\data\file.txt"会返回DRIVE_NO_ROOT_DIR - 返回值为
DRIVE_REMOVABLE才表示可移动磁盘（U 盘、SD 卡、外置 USB 硬盘等）；注意部分 USB 接口的 SSD 可能被识别为DRIVE_FIXED，这是系统底层报告决定的，无法绕过 - 需包含
<windows.h>，且链接时不需要额外库（kernel32.lib默认已链接）
Linux 下没有统一“可移动磁盘”概念，得靠 sysfs 和 udev 属性
Linux 没有等价于 GetDriveType 的系统调用。是否“可移动”取决于设备本身的物理属性和内核如何暴露它，常见做法是检查 /sys/block/*/removable 文件内容。
- 先从路径反推设备名：用
stat()获取st_dev，再通过major()/minor()构造/sys/dev/block/M:m/removable路径 - 读取该文件，内容为
"1"表示可移动（如 U 盘、SD 卡），"0"表示不可移动（如内置 SATA SSD） - 注意：NVMe 设备即使插在 USB-C 扩展坞中，也可能被识别为
removable=0，因为内核按协议而非物理接口判断 - 不要依赖
/proc/mounts或挂载选项（如noatime），它们和“可移动性”无关
C++ 跨平台封装要注意路径归一化和权限边界
写跨平台函数时，别试图抽象出统一语义——Windows 的 “removable” 和 Linux 的 “removable” 实际含义不同，强行合并容易误判。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- Windows 侧优先用
GetDriveType，避免用 WMI 查询（启动慢、权限要求高） - Linux 侧别硬解
/proc/partitions或lsblk输出，文本解析不稳定；坚持走sysfs文件读取，失败则默认不可移动 - 路径输入必须先做
std::filesystem::canonical()或至少std::filesystem::absolute()，否则相对路径或符号链接会导致驱动器推导错误 - 对无权访问的路径（如
/root/xxx），Linux 下读sysfs可能失败，此时应返回不确定态（如抛异常或返回std::nullopt），而不是假定为固定磁盘
常见误判场景：为什么 U 盘有时被识别为固定磁盘？
这不是代码写错了，而是硬件/固件/驱动层决定的。比如：
立即学习“C++免费学习笔记（深入）”；
- 某些 USB 3.0 移动硬盘盒使用 UASP 协议 + SCSI 指令集，Windows 将其报告为
DRIVE_FIXED - Linux 下 NVMe SSD 插在 Thunderbolt 4 扩展坞中，
/sys/block/nvme0n1/removable仍为"0"，因为 PCIe 协议本身不定义“可移动”属性 - 虚拟机中挂载的 ISO 镜像或 iSCSI LUN，可能被报告为
DRIVE_REMOVABLE，但显然不是物理可移动设备
实际业务中，如果目标是“用户可安全拔出的设备”，除了驱动器类型，还得结合是否正在被占用（GetVolumeInformation + FindFirstVolume / lsof）、是否启用写缓存等状态综合判断。单靠一个 API 不足以覆盖所有拔盘安全场景。
