Windows通过GetFileInformationByHandle检查FILE_ATTRIBUTE_SPARSE_FILE标志判断稀疏文件属性，Linux则需结合stat比较st_size与st_blocks及lseek(SEEK_HOLE)检测实际空洞，二者逻辑本质不同。
Windows下用GetFileInformationByHandle判断稀疏文件
Windows API 提供了直接、可靠的方式：调用 GetFileInformationByHandle 获取 BY_HANDLE_FILE_INFORMATION 结构体，检查其 dwFileAttributes 字段是否包含 FILE_ATTRIBUTE_SPARSE_FILE 标志。
- 必须先用
CreateFile以GENERIC_READ权限打开文件（不能只用OPEN_EXISTING，否则可能因权限不足失败） - 该属性是文件创建/设置时由系统标记的，不是运行时计算得出——所以它反映的是“是否被声明为稀疏”，而非“当前实际是否稀疏”
- 如果文件句柄无效或权限不够，
GetLastError()会返回ERROR_ACCESS_DENIED或ERROR_INVALID_HANDLE，需提前检查
HANDLE h = CreateFile(L"test.dat", GENERIC_READ, FILE_SHARE_READ, nullptr, OPEN_EXISTING, 0, nullptr);
if (h == INVALID_HANDLE_VALUE) { /* 处理错误 */ }
BY_HANDLE_FILE_INFORMATION info = {};
if (GetFileInformationByHandle(h, &info)) {
bool is_sparse = (info.dwFileAttributes & FILE_ATTRIBUTE_SPARSE_FILE) != 0;
}
CloseHandle(h);
Linux下需结合stat和ioctl检测ext4/xfs稀疏性
Linux 没有统一的“稀疏文件”文件系统属性，判断依赖两层：一是看逻辑大小是否远大于物理占用（st_size > st_blocks * 512），二是对支持的文件系统（如 ext4、xfs）调用 ioctl(fd, FS_IOC_GETFLAGS, &flags) 查看是否设置了 FS_COMPR_FL 或更关键的 FS_SPARSE_FL（注意：该标志并非所有内核版本都定义，且 xfs 实际不使用此标志）。
-
st_blocks是磁盘上实际分配的 512 字节块数，若st_size / 512 > st_blocks，大概率存在空洞，但不等于文件被显式标记为稀疏 - ext4 中没有专用稀疏标志；xfs 使用
XFS_IOC_FSGETXATTR查询扩展属性，其中XFS_XFLAG_EXTSIZE等与稀疏无关，真正相关的是写入时是否启用allocsize或挂载选项nobarrier—— 但这些不影响“判断”，只影响行为 - 最实用的做法是：先
stat()对比st_size和st_blocks，再尝试lseek(fd, offset, SEEK_HOLE)找第一个空洞——若成功定位，则说明存在稀疏区域
跨平台代码别硬套Windows逻辑到Linux
有人把 Windows 的 FILE_ATTRIBUTE_SPARSE_FILE 检查逻辑直接移植到 Linux，结果永远返回 false——因为 Linux 的 stat.st_flags 不包含该字段，ioctl 也无对应等价调用。
- 不要在 Linux 上检查
st_flags & SF_SPARSE（该常量不存在，编译不过） - 不要假设
open()返回的 fd 调用ioctl(fd, FS_IOC_GETFLAGS, ...)就能拿到稀疏标志——ext4 根本不设这个位，xfs 也不用它表示稀疏 - POSIX 标准里没有“稀疏文件标识”，C++ 标准库（如
std::filesystem::file_size）只返回st_size，无法告诉你是否稀疏
稀疏文件判断结果 ≠ 稀疏行为表现
一个文件可能未被标记为稀疏（如 Windows 上没调用 DeviceIoControl(..., FSCTL_SET_SPARSE, ...)），但仍因写入空洞而实际占用极少磁盘空间；反之，标记为稀疏的文件若后续被填满，就不再稀疏——但属性仍保留。
立即学习“C++免费学习笔记（深入）”；
- Windows 上
FILE_ATTRIBUTE_SPARSE_FILE只控制后续写入是否自动跳过零填充（即是否启用“稀疏写入优化”），不反映当前数据分布 - Linux 下
lseek(fd, 0, SEEK_HOLE)成功返回位置，才真正证明该文件存在可跳过的空洞；仅靠st_size != st_blocks * 512是间接证据，可能因文件系统块对齐、日志开销等产生偏差 - 某些场景（如容器镜像、数据库快照）会主动创建稀疏文件，但应用层若只依赖属性判断，可能漏掉未标记但实际稀疏的文件
