GetDiskFreeSpaceEx仅返回字节数而非扇区数，因Win32抽象了物理扇区；需用GetDiskFreeSpace获取每扇区字节数再换算，但结果仍非真实物理扇区；底层需求应使用DeviceIoControl或WMI。
GetDiskFreeSpaceEx 获取总/空闲字节数，但不是扇区数
Win32 没有直接暴露“扇区数”的 API。所有标准接口（包括 GetDiskFreeSpaceEx）只返回字节数——这是设计使然，因为扇区大小在不同设备上不统一（512B、4KB、甚至更大），OS 层面抽象掉了物理扇区概念。
实际开发中，你真正需要的几乎总是「可用空间字节数」，而非扇区数。如果硬要换算，必须先知道卷的扇区大小（即簇大小 × 每簇扇区数），而这个值本身就得查。
-
GetDiskFreeSpaceEx返回的是逻辑卷的总字节数、可用字节数（含管理员预留）、以及用户可用字节数（受配额限制） - 它不区分“已分配但未写入”或“坏道隔离区”，结果是文件系统视角的干净数据
- 调用前需确保路径指向根目录（如
"C:\"），否则可能返回错误或误导性值
GetDiskFreeSpace 得到每簇扇区数和簇大小
想凑出扇区数，唯一可行路径是组合 GetDiskFreeSpace 的四个输出参数：它返回每簇字节数、每扇区字节数、每簇扇区数、总簇数。其中 lpSectorsPerCluster 就是你能拿到的最接近“物理扇区计数”的值——但它其实是文件系统分配单元（簇）内部的扇区组织数，不是整盘物理扇区总数。
示例关键片段：
立即学习“C++免费学习笔记（深入）”；
ULARGE_INTEGER totalBytes, freeBytes; BOOL ok = GetDiskFreeSpaceEx(L"C:\", &freeBytes, &totalBytes, nullptr); // totalBytes.QuadPart 是总字节数，不是扇区数
- 若真要算总扇区数：需先用
GetDiskFreeSpace取得lpBytesPerSector，再用totalBytes.QuadPart / lpBytesPerSector向下取整 - 但注意：NTFS 卷可能包含隐藏元数据区（如 $MFTMirr 所占空间），这部分字节不计入
GetDiskFreeSpaceEx的 total，所以除法结果仍会偏高 -
lpBytesPerSector常见为 512 或 4096，但某些 SSD 或叠瓦磁盘可能报告 4096 而实际物理扇区是 8192，API 不保证与硬件一致
需要真实物理扇区数？得绕道 WMI 或 IOCTL
如果你在做磁盘底层工具（比如坏道扫描、裸设备备份），确实需要物理 LBA 范围，那 Win32 文件 API 已经不够用了。必须用更底层的方式：
- 通过
DeviceIoControl向物理驱动器句柄（\\.\PhysicalDrive0）发送IOCTL_DISK_GET_LENGTH_INFO，得到总字节数，再除以IOCTL_DISK_GET_DRIVE_GEOMETRY_EX返回的Geometry.BytesPerSector - WMI 查询
Win32_DiskDrive类的Size和SectorsPerTrack等字段，但这些是固件报告值，可能被 RAID/HBA 层虚拟化 - 必须以管理员权限打开设备句柄，普通进程会触发
ERROR_ACCESS_DENIED - 对正在使用的系统盘执行此类操作风险极高，Windows 可能拒绝访问或返回过时缓存值
别把“可用扇区数”当“可写扇区数”
即使你成功算出某个数字，它也大概率不是你能安全写的扇区数。NTFS 默认保留约 1/8 总空间给管理员，GetDiskFreeSpaceEx 的 lpFreeBytesAvailable 才是应用能用的上限；而 lpTotalNumberOfFreeBytes 包含预留区，容易误判。
- SSD 的 TRIM、FTL 映射、OP 区都会让“空闲扇区”在固件层不可见
- 卷影复制（VSS）快照会占用额外空间，但不体现在
GetDiskFreeSpaceEx中 - 如果程序目标是“判断是否够写一个 2GB 文件”，直接比
lpFreeBytesAvailable和文件大小，别自己转扇区
物理扇区数是个模糊概念，在现代存储栈里越往下钻，越难定义“谁的扇区”。多数场景下，字节数就是事实上的单位。
