Windows下用GetDriveType判断可移动磁盘路径最可靠：先提取驱动器根路径（如"E:"），再调用GetDriveType，返回DRIVE_REMOVABLE即表示U盘、SD卡等可移动设备；注意USB硬盘可能被识别为DRIVE_FIXED，且UNC路径或非根路径会失效。
Windows下用 GetDriveType 判断可移动磁盘路径
直接看路径所在驱动器类型是最可靠的方式。C++ 标准库不提供跨平台磁盘类型识别，Windows API 的 GetDriveType 是唯一稳定方案。它不关心路径是否存在或是否可读，只看驱动器根目录的物理属性。
关键点：必须先提取路径的根目录（如 "E:\foo\bar" → "E:\"），再传给 GetDriveType。传入任意子路径都会返回 DRIVE_NO_ROOT_DIR 或错误结果。
- 用
PathStripToRoot（shlwapi.h）或手动截取到冒号+反斜杠为止 - 确保路径是绝对路径；相对路径需先用
GetFullPathName转换 - 返回值为
DRIVE_REMOVABLE才表示可移动磁盘（U 盘、SD 卡、外置硬盘等） - 注意：某些 USB 硬盘可能被识别为
DRIVE_FIXED（取决于固件和 Windows 驱动），这不是 bug，而是系统层面分类
Linux 下没有等价的 GetDriveType，得靠 /sys/block
Linux 没有统一 API 判断“可移动性”，只能查设备 sysfs 属性。核心依据是 /sys/block/*/removable 文件内容是否为 1，但前提是得从路径反推出对应的 block device。
步骤链较长：路径 → mount point → device node（如 /dev/sdb1）→ block name（sdb）→ /sys/block/sdb/removable。中间任一环失败（比如路径不在挂载点下、是 bind mount、或 device 被卸载）都会中断。
立即学习“C++免费学习笔记（深入）”；
- 用
statvfs获取文件系统挂载点，再查/proc/mounts或findmnt命令输出（不推荐 runtime 调用 shell） - 解析
/proc/self/mountinfo更健壮，但格式复杂；建议用 libmount（systemd 提供）简化 -
/sys/block/*/removable为1表示硬件支持热插拔，但不等于用户能随时拔掉（比如正在写入） - 注意：NVMe SSD、某些 USB-C 外置盘可能被标记为
0，即使物理上可拔——这是内核根据设备描述符决定的
跨平台封装要避开“可移动”这个模糊词
“可移动磁盘”在不同系统语义差异太大：Windows 侧重接口类型（USB/IEEE1394），Linux 侧重硬件能力（removable flag），macOS 还要看 IOKit 的 kIOMediaRemovableKey。强行统一命名容易误导。
实际工程中，更稳妥的做法是分场景暴露底层能力：
- 需要弹出前检查？用 Windows
DeviceIoControl(... IOCTL_STORAGE_CHECK_VERIFY)+ Linuxioctl(fd, BLKRRPART)类操作 - 只是 UI 上灰掉“安全删除”按钮？优先查 Windows
DRIVE_REMOVABLE，Linux 查removable == 1且不是 LVM/RAID 成员 - 避免用“is_removable()”这种函数名，改用
is_hotpluggable_drive()或supports_safe_ejection()，让调用方清楚边界
常见误判：NTFS 卷、网络驱动器、符号链接
路径本身不决定磁盘类型，驱动器类型才决定。很多误判来自没处理好路径归一化。
- NTFS 挂载点（如
C:\mount\usb挂载了 E:）：GetDriveType查的是C:，不是真实后端设备 - 网络驱动器（
Z:映射到 SMB）：返回DRIVE_REMOTE，不是DRIVE_REMOVABLE，哪怕后端是 U 盘 - 符号链接指向可移动盘：Windows 下
GetDriveType对 symlink 目标路径有效，但需先用GetFinalPathNameByHandle解析，否则仍查原路径所在驱动器 - 长路径（
\\?\前缀）：必须保留前缀传给GetDriveType，否则截断导致失败
真正难的不是调 API，而是理解“可移动”在当前上下文里到底指什么——是硬件特性、用户操作预期，还是权限控制依据。这点不厘清，代码写得再全也救不了逻辑漏洞。
