应使用 FileSystemInfo.Attributes 配合 ReparsePoint 检查并比对 Path.GetFullPath 与 FileInfo.FullName 是否相等来可靠判断符号链接，而非依赖 File.GetAttributes(path) 返回的 FileAttributes.ReparsePoint。
判断路径是否为符号链接（C# File.GetAttributes 的陷阱）
Windows 和 Linux 上的符号链接（symlink）在 .NET 中不会自动解析，但很多 API（比如 File.Exists、Directory.GetFiles）默认会跟随链接——这正是漏洞温床。别直接信 File.GetAttributes(path) 返回的 FileAttributes.ReparsePoint：它只对目录级符号链接（junction 或 symlink 目录）稳定有效；对文件级 symlink，尤其跨卷或由非管理员创建的，可能返回 0 或误判。
- 真正可靠的方式是调用 Win32
GetFileAttributesEx（Windows）或stat（Linux/macOS），但 .NET 6+ 提供了更安全的替代：FileSystemInfo.Attributes配合ReparsePoint检查 + 手动比对原始路径与解析后路径 - 示例：先用
Path.GetFullPath(path)获取规范路径，再用new FileInfo(path).FullName，若二者不等，大概率遇到 symlink（注意：需在相同驱动器/挂载点下比对，否则GetFullPath可能补全失败） - 不要依赖
File.ReadLink（.NET 5+）——它仅对 *已知* 是 symlink 的路径有效，而你正要判断它是不是
禁止自动解析路径的 API（File.Open / Directory.EnumerateFiles 的危险模式）
这些方法默认启用符号链接跟随（follow symlinks），一旦用户可控路径含 symlink，就可能读写任意位置文件，绕过路径白名单或沙箱限制。
-
File.Open(path, FileMode.Open, FileAccess.Read, FileShare.None, bufferSize, FileOptions.None)：最后一个参数FileOptions.None是默认值，隐式开启跟随。必须显式传入FileOptions.OpenReparsePoint才能打开链接本身（而非目标），再配合手动校验 -
Directory.EnumerateFiles(root, pattern, SearchOption.AllDirectories)：递归时会无条件跟随所有 symlink，哪怕root在C:\app\data\，一个指向C:\Windows\System32的 symlink 就会让整个系统目录被遍历 - 解决方案不是禁用递归，而是改用
Directory.EnumerateFileSystemEntries+ 逐项检查FileSystemInfo.Attributes & FileAttributes.ReparsePoint，发现即跳过或报错
验证路径是否在预期范围内（Path.GetRelativePath 不够用）
很多人用 Path.GetRelativePath(baseDir, userInputPath) 判断是否“在目录内”，但这个函数不处理 symlink：如果 baseDir 下有个 symlink 指向 /etc/shadow，GetRelativePath 仍返回 ../etc/shadow 这种看似合法的相对路径。
- 正确做法是获取真实物理路径：
Path.GetFullPath(new DirectoryInfo(userInputPath).FullName)（注意：这里DirectoryInfo构造函数会跟随链接，所以必须先确保userInputPath不含未校验的 symlink） - 更稳妥的是用
Path.GetFullPath后，再用string.StartsWith比较物理路径前缀，且必须以路径分隔符结尾（如allowedRoot + Path.DirectorySeparatorChar），避免C:\safe匹配到C:\safeguard - Linux 上还要注意挂载点边界——
/proc/mounts或stat -c "%d" .对应的 device ID 才是真实隔离依据，仅靠路径字符串无效
.NET 版本与平台差异（FileOptions.OpenReparsePoint 在 Linux 的失效）
这个标志在 Windows 上能让你打开 symlink 文件本身，在 Linux/macOS 上却会被静默忽略（.NET Runtime issue #43921），导致你以为关掉了跟随，其实没关。
- Linux 下唯一可靠方式是用
System.IO.FileSystemWatcher或statP/Invoke 检查st_mode & S_IFLNK，再拒绝处理 - .NET 7+ 引入
File.GetLinkTarget，但它要求路径已是 symlink，不能用于前置检测；且 macOS 上部分 HFS+ 符号链接类型（如 alias）不被识别 - 跨平台服务务必把 symlink 检查逻辑下沉到启动时：用
Environment.OSVersion.Platform分支，并在 CI 中用不同 OS 镜像跑路径遍历测试
最麻烦的不是技术实现，而是 symlink 可能藏在路径中间任意一级——比如 ./data/user/123/../@symlink/config.json，需要完整展开并逐段校验。别假设用户只会在末尾动手脚。
