硬链接只能在同一NTFS卷内创建，跨卷会因ERROR_NOT_SAME_DEVICE失败；需管理员权限和SeCreateHardLinkPrivilege；File.CreateHardLink不支持覆盖或目录；链接数须用GetFileInformationByHandle获取dwNumberOfLinks判断。
硬链接在C#里不能直接跨卷创建
Windows NTFS硬链接只能指向同一卷上的文件，CreateHardLink API 调用失败时通常返回 ERROR_NOT_SAME_DEVICE。这不是C#封装的问题，而是NTFS底层限制——硬链接本质是目录项对同一MFT记录的多个引用，跨卷即跨MFT，不可能。
实操建议：
- 调用前先用
Path.GetPathRoot比较源文件和目标路径的根目录，不一致就提前报错 - 不要依赖
File.CreateHardLink（.NET 6+）自动处理跨卷，它只是对CreateHardLinkW的封装，失败时抛IOException，异常信息里含5（拒绝访问）或267（目录名无效），实际多是卷不匹配 - 管理员权限不是可选项：硬链接需
SeCreateHardLinkPrivilege，普通用户默认没有，必须以管理员身份运行或手动授予权限
.NET 6+ 的 File.CreateHardLink 用法与陷阱
这是目前最简洁的API，但容易误以为它能“创建新链接文件”，其实它只在指定路径新建一个硬链接入口，原文件必须已存在且不可被删除（否则所有硬链接都失效）。
常见错误现象：IOException 提示“句柄无效”或“参数错误”，大概率是目标路径已存在（硬链接不能覆盖）、目标是目录、或路径含非法字符（如末尾空格、. 或 ..）。
实操建议：
- 确保目标路径不存在：
if (File.Exists(linkPath)) throw new InvalidOperationException("Link path already exists"); - 目标路径必须是完整文件路径，不能是目录；源路径也必须是文件（对目录建硬链接会失败）
- 注意编码：如果路径含Unicode字符（如中文），确保控制台/IDE使用UTF-8，否则
CreateHardLink可能静默截断 - 示例：
File.CreateHardLink(@"C:\data\report_link.txt", @"C:\data\report_orig.txt");
如何判断一个文件是否是硬链接，以及有多少个链接
硬链接本身不可见，Windows资源管理器完全不显示链接数。得靠 GetFileInformationByHandle 查 dwNumberOfLinks 字段——这才是唯一可靠方式。
性能影响很小，但要注意：该值反映的是当前打开句柄所在路径对应的MFT记录的链接总数，不是“这个路径是链接还是原文件”的布尔判断。
实操建议：
- 用
File.Open获取SafeFileHandle，再调用GetFileInformationByHandle（需P/Invoke） -
dwNumberOfLinks > 1表示至少还有一个其他硬链接存在；等于1不代表“原始文件”，只是当前时刻只有这一个引用 - 别用文件大小、创建时间、最后写入时间对比来“猜”是否为硬链接——它们完全同步，毫无区分度
- 没有纯托管API能绕过P/Invoke获取链接数，.NET标准库至今未暴露此字段
解析硬链接？不存在的——硬链接没有“源”和“目标”之分
这是最容易被误解的一点：硬链接不是快捷方式，没有元数据指向“另一个文件”。所有硬链接路径地位完全平等，删除其中任意一个，只要还有别的链接存在，文件数据就还在。
所以所谓“解析硬链接”其实是伪需求。你无法从一个路径反查“它链接到哪个路径”，因为根本没存这个信息。
实操建议：
- 若业务需要追踪文件关系，必须自己维护映射表（如数据库记录路径哈希 + 链接组ID）
- 可用
GetFileInformationByHandle获取VolumeSerialNumber和FileIndex（高位+低位），这两者组合才是文件在卷内的唯一标识，可用于关联多个路径 - 注意
FileIndex在磁盘整理或某些备份操作后可能变化，不能长期依赖
硬链接的不可逆性是核心复杂点：一旦创建，就没有“主副”概念，也没有反向追溯能力。所有操作都基于卷内MFT记录，而.NET只提供了最表层的创建入口，底层细节得自己补全。
