用 getfileattributes 检查 file_attribute_sparse_file 是判断 windows 稀疏文件最直接方式，需 p/invoke 调用且路径必须为本地 ntfs 绝对路径；返回 true 仅表示属性被设置，不验证实际空洞存在。
用 GetFileAttributes 检查 FILE_ATTRIBUTE_SPARSE_FILE
Windows 系统中，稀疏文件（Sparse File）的标识是文件属性中的 FILE_ATTRIBUTE_SPARSE_FILE 标志。C# 里最直接的方式是调用 Win32 API GetFileAttributes，再检查返回值是否包含该标志。
注意：.NET 原生类库（如 FileInfo）**不暴露稀疏属性**，必须 P/Invoke。
- 需引用
System.Runtime.InteropServices - 路径必须是本地 NTFS 卷上的绝对路径（UNC 或映射盘符均可，但不能是网络重定向器如 OneDrive/SharePoint 虚拟路径）
- 调用前建议先确认文件存在且可访问，否则可能返回
INVALID_FILE_ATTRIBUTES（即 -1）
GetFileAttributes 的典型调用方式
以下是最小可行代码片段，不含异常包装：
[DllImport("kernel32.dll", SetLastError = true)]
private static extern uint GetFileAttributes(string lpFileName);
<p>private const uint FILE_ATTRIBUTE_SPARSE_FILE = 0x00000200;</p><p>public static bool IsSparseFile(string path)
{
var attr = GetFileAttributes(path);
if (attr == 0xFFFFFFFF) return false; // INVALID_FILE_ATTRIBUTES
return (attr & FILE_ATTRIBUTE_SPARSE_FILE) != 0;
}这个函数返回 true 仅表示系统当前将该文件标记为稀疏文件——它不验证实际数据布局或稀疏区域是否真实存在。
- 即使文件已被写满（无空洞），只要曾被设为稀疏并保留了属性，仍会返回
true - 若文件被复制到非 NTFS 卷（如 FAT32、exFAT），稀疏属性丢失，
GetFileAttributes不会返回该标志 - 符号链接、硬链接本身不继承稀疏属性；判断目标文件需先解析到实际路径（可用
GetFinalPathNameByHandle）
为什么不用 DeviceIoControl 查 FSCTL_QUERY_ALLOCATED_RANGES？
有人会想到用更底层的 FSCTL_QUERY_ALLOCATED_RANGES 来确认“是否真有未分配区域”，但这不是判断“是否为稀疏文件”的等价操作：
- 一个文件可以是稀疏类型但当前所有簇都已分配（即没有空洞），此时仍属稀疏文件
- 反之，一个非稀疏文件在 NTFS 上也可能因压缩或重删产生逻辑空洞，但它不具备
FILE_ATTRIBUTE_SPARSE_FILE -
FSCTL_QUERY_ALLOCATED_RANGES开销大、需打开句柄、权限更高，且结果依赖于当前分配状态，不适合做元数据判定
所以，除非你要分析空间使用效率或定位空洞位置，否则没必要绕远路。
常见误判场景和权限问题
实际使用中，返回 false 并不一定代表“不是稀疏文件”：
- 调用进程没有读取文件属性的权限（例如某些受保护系统目录下的文件），
GetFileAttributes可能失败并返回 -1 - 路径指向重解析点（如目录交接点、卷挂载点），而目标卷不支持稀疏文件，属性可能被忽略
- 通过 .NET Core/.NET 5+ 在 Linux/macOS 上运行时，该 API 完全不可用（会抛
DllNotFoundException），需提前判断运行环境 - 某些备份或同步工具（如 VSS 快照内文件）可能临时隐藏或修改属性位
真正可靠的判断只发生在具有完整 NTFS 属性访问权的 Windows 环境中——其他情况要么跳过，要么降级处理为“未知”。
