判断路径是否为符号链接（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:\safeguardLinux 上还要注意挂载点边界——
/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，需要完整展开并逐段校验。别假设用户只会在末尾动手脚。
