用 GetFileInformationByHandle
读取 NTFS 文件 ID（FileIndex）
Windows NTFS 下的“文件唯一标识”实际是
FILE_ID_INFO中的
FileId，它由 8 字节高位（
VolumeSerialNumber）和 8 字节低位（
FileId）组成，跨卷不唯一，但在同一卷内可稳定标识一个文件（即使重命名、移动）。C# 没有直接封装该结构的 API，必须调用 Win32：
GetFileInformationByHandle配合
FILE_ID_INFO。
关键点：
必须使用FileOptions.Asynchronous或确保句柄可被查询（
FileAccess.Read足够，无需写权限） 目标文件需在 NTFS 卷上；FAT32/exFAT 返回
0或无效值
FileId是逻辑 ID，不是 inode —— Windows 不暴露传统 Unix inode，但语义等价
var h = CreateFile(path, FileAccess.Read, FileShare.Read, IntPtr.Zero, FileMode.Open, 0, IntPtr.Zero);
if (h == INVALID_HANDLE_VALUE) throw new IOException();
try {
var info = new FILE_ID_INFO();
if (!GetFileInformationByHandleEx(h, FileInfoByHandleClass.FileIdInfo, ref info, sizeof(FILE_ID_INFO)))
throw new IOException($"GetFileInformationByHandleEx failed: {Marshal.GetLastWin32Error()}");
return info.FileId.ToUInt64(); // 注意：低位在前，高位在后，ToUInt64 取的是低8字节
}
GetFileInformationByHandleEx
的 FileIdInfo
和 FileNameInfo
区别
容易混淆的是：
FileNameInfo返回的是路径名（含相对路径），而
FileIdInfo才返回真正稳定的卷内 ID。前者会随重命名/移动变化，后者不会。
常见误用场景：
用GetFileInformationByHandleEx(..., FileNameInfo, ...)当作唯一标识 → 错，只是当前路径快照 没检查
dwFileType就假设是 NTFS → FAT32 下
FileId全为 0，需提前验证卷格式（可用
GetVolumeInformation） 直接把
FileId当作 64 位整数比较 → 必须同时比对
VolumeSerialNumber，否则跨卷碰撞风险高
替代方案：用 USN Journal
或 ObjectID
？
ObjectID是可设置的 GUID，需手动调用
SetFileInformationByHandle设置，且默认为空；它不自动分配，也不随文件创建产生，不适合“获取已有文件唯一 ID”的需求。
USN Journal记录变更序号（
Usn），但它不是文件标识，而是操作日志编号，同一文件多次修改对应多个 USN，不可用于识别文件本身。
所以——
要“只读、不改、跨重命名/移动仍一致” → 坚持用FileIdInfo+
VolumeSerialNumber要“跨卷全局唯一” → 必须自己拼接
{VolumeSerialNumber}-{FileId} 并以字符串或结构体形式保存，不能只存 FileId要“加密哈希式不可逆标识” → 可考虑
GetFileHash（如 SHA256），但性能差、内容变则 ID 变，语义不同
注意 FILE_ID_INFO
在 .NET 5+ 的跨平台陷阱
.NET 5+ 引入了
File.GetFileId（仅 Windows），但它内部就是封装了
GetFileInformationByHandleEx，行为一致。但要注意： 该方法在非 Windows 平台抛
PlatformNotSupportedException，不会静默失败 它返回的是
ReadOnlySpan<byte></byte>，长度 16（8 字节 VolumeSerialNumber + 8 字节 FileId），不是
ulong若你用
File.GetFileId(path)后直接
.ToArray()再
BitConverter.ToUInt64取前 8 字节 → 错，那只是
FileId低位，漏了卷序列号，无法防碰撞
真正安全的做法是始终把 16 字节当整体处理，或显式拆成两个
ulong字段比对。
