文件真实磁盘占用需用st_blocks×512（Linux/macOS）或GetCompressedFileSize（Windows），而非st_size；st_blocks单位恒为512字节，非文件系统块大小，Windows下还需注意大文件截断问题。
用 stat 系统调用读取 st_blocks 字段
逻辑大小（st_size）是文件内容字节数，而真实磁盘占用看的是分配的块数 × 块大小。Linux/macOS 下必须通过 stat 获取 st_blocks（已分配 512 字节块的数量），再乘以 512。Windows 不直接暴露这个值，得换路子。
实操建议：
立即学习“C++免费学习笔记（深入）”；
-
st_blocks单位固定为 512 字节，不是文件系统 block size，别误用st_blksize - 用
struct stat sb; stat("path", &sb)，别用fstat除非你已有 fd - 注意符号：
st_blocks是blkcnt_t，可能为 signed，但实际非负，强制转uint64_t更稳 - 示例：
struct stat sb;<br>if (stat("data.bin", &sb) == 0) {<br> off_t disk_bytes = sb.st_blocks * 512;<br>}
Windows 上用 GetCompressedFileSize 或 GetFileInformationByHandle
Windows 没有等价于 st_blocks 的公开字段。NTFS 压缩或稀疏文件会让逻辑大小和磁盘占用严重偏离，此时 GetCompressedFileSize 返回的是实际写入磁盘的字节数（含压缩后大小），更贴近“真实存储大小”本意。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 优先用
GetCompressedFileSize：它对压缩/未压缩文件都有效，返回值就是磁盘上占的字节数（不是块数） - 若需区分压缩与未压缩，再补调
GetFileInformationByHandle查dwFileAttributes是否含FILE_ATTRIBUTE_COMPRESSED - 注意：该函数在文件大于 4GB 时，低 32 位可能截断，务必用
GetCompressedFileSizeEx（Win10 1709+）或手动组合高位/低位 - 示例：
DWORD low = GetCompressedFileSizeA("log.dat", &high);<br>uint64_t disk_bytes = ((uint64_t)high << 32) | low;
稀疏文件和压缩文件让两者差异极大
逻辑大小是 cat file | wc -c 的结果；真实大小取决于文件系统是否实际写了那些字节。稀疏文件（如 dd seek=1G count=0 创建的）逻辑大小很大，但磁盘占用几乎为 0；NTFS 压缩文件则相反——逻辑大小 100MB，磁盘可能只占 30MB。
常见错误现象：
- 用
ls -l当磁盘用量看，结果发现df没变化，但ls -lh显示文件很大 - 备份脚本按
st_size预估空间，结果目标盘爆满——因为没算压缩/稀疏带来的偏差 - 跨平台工具硬套 Linux 的
st_blocks * 512到 Windows，得到完全错误的数字
跨平台封装时别试图统一接口
没有银弹函数能同时在 Linux/macOS/Windows 上返回一致的“真实磁盘大小”。硬做抽象只会掩盖差异、引入 bug。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 按平台条件编译：Linux/macOS 走
stat+st_blocks，Windows 走GetCompressedFileSize - 不要封装成
get_disk_size(const char*)这种看似通用的函数——调用方必须清楚自己拿到的是块估算值（Linux）还是压缩后字节数（Windows） - 如果业务真需要严格可比，只能放弃“真实磁盘大小”，改用统一采样方式：比如用
du -B1 --apparent-size（逻辑） vsdu -B1（实际），但那已脱离 C++ API 层面
最易被忽略的一点：同一文件在不同文件系统上，“真实大小”的定义本身就不同。ext4 的块映射、XFS 的 extent、NTFS 的压缩流、APFS 的克隆块——这些底层机制决定了你根本没法靠一个数字概括所有场景。能做的，只是按当前 OS 和 FS 类型，取它愿意告诉你的那个最接近的值。
