GetVolumeInformationA 获取卷标必须传根目录路径（如"C:\"），传驱动器字母（如"C:"）会返回空卷标且错误码为0；建议用GetLogicalDrives()枚举驱动器再构造正确路径。
说到Windows下获取卷标，很多人的第一反应就是调用GetVolumeInformationA。但这里有个坑——传参时必须用带反斜杠的根目录路径，比如"C:\"，而不是驱动器字母"C:"。一旦传错，函数会返回成功，但lpVolumeNameBuffer里啥也没有，GetLastError()还给你返回0，排查起来相当迷惑。
那怎么绕开这个坑？实际操作中建议这样处理：
- 先用
GetLogicalDrives()拿到位掩码，然后通过for循环逐位检查（比如for (int i = 0; i < 26; i++)），拼出类似char rootPath[] = "A:\"的路径格式。 - 调用前确保
lpVolumeNameBuffer缓冲区至少256字节，否则可能被截断甚至触发缓冲区溢出警告。 - 特别要注意：无介质的光驱或未格式化的U盘上，函数会失败，
GetLastError()返回ERROR_NOT_READY，这种情况直接跳过即可。
EnumWindowsVolumes 需要 Windows 10 1809+，且权限无额外要求
如果你的目标系统比较新（Windows 10 1809或Windows Server 2019起），还有一套更优雅的方案：用FindFirstVolumeW/FindNextVolumeW遍历所有卷的GUID路径（格式像\\?\Volume{a1b2c3d4-...}\），然后对每个卷调用GetVolumeInformationByHandleW。这套API完全不依赖盘符，能拿到NTFS、ReFS甚至未分配盘符的卷信息。
关键点要注意几个：
- 必须使用宽字符版本（W后缀），因为
FindFirstVolumeA在Windows中根本不存在。 - 每个卷GUID路径需要先用
CreateFileW以GENERIC_READ和FILE_FLAG_BACKUP_SEMANTICS打开，才能传给GetVolumeInformationByHandleW。 - 打开失败时常见原因是权限不足——但普通用户进程其实也能成功，只要不访问卷内文件。失败时
GetLastError()多是ERROR_ACCESS_DENIED，可以安全忽略，继续下一个卷。
卷标为空或乱码？检查文件系统和代码页
NTFS卷标默认用UTF-16存储，但GetVolumeInformationA会按当前系统ANSI代码页（比如GBK）尝试转换。如果卷标包含中文且系统locale不匹配，显示出来就是乱码或空字符串。相比之下，GetVolumeInformationW始终返回原始UTF-16，更靠谱。
具体应对方式：
- 优先使用
GetVolumeInformationW，然后自己做UTF-16到UTF-8的转换（比如用WideCharToMultiByte(CP_UTF8, ...)）。 - 不要假设所有卷都有卷标：FAT32卷标最长11字符且不支持Unicode；exFAT卷标支持UTF-16，但部分旧设备写入时可能只存ASCII。
- 某些加密卷（如BitLocker挂载后）或网络驱动器（WebDA V、OneDrive挂载点）可能返回空卷标，这是正常行为，不是代码bug。
GetDriveTypeA 判断是否真挂载，避免无效调用
并不是所有逻辑驱动器都对应真实挂载的卷。比如"A:\"可能是软驱（已淘汰）、"D:\"可能是DVD光驱但没放光盘、"Z:\"可能是断开的网络映射。如果盲目对每个驱动器都调用GetVolumeInformation，不仅拖慢速度，还可能触发弹窗（比如光驱无盘时弹出“请插入磁盘”）。
推荐的做法是：
- 先用
GetDriveTypeA("C:\")判断类型：DRIVE_FIXED（本地硬盘）、DRIVE_REMOVABLE（U盘/SD卡）、DRIVE_REMOTE（网络驱动器）才值得继续查卷标；DRIVE_NO_ROOT_DIR或DRIVE_UNKNOWN直接跳过。 - 对于
DRIVE_CDROM类型，仅当GetDriveType返回该值且后续GetVolumeInformation成功时才取卷标；否则大概率是空仓，卷标无意义。 - 网络驱动器（
DRIVE_REMOTE）的卷标通常来自服务器共享名，而非远程卷本身的NTFS卷标，行为不一致，需要单独说明用途。
实际跑通的关键，是把驱动器枚举、类型过滤、路径格式、编码处理这四步串成闭环。最容易忽略的一点是：卷标为空不等于失败，而是文件系统或挂载状态决定的合理结果，别把它当成bug来查。
