path.getfullpath是处理相对路径转绝对路径的首选方法，它自动解析..、.、斜杠混合等，但依赖当前工作目录；工作目录不可靠时应先用可靠基准路径（如appcontext.basedirectory）组合再调用。
用 Path.GetFullPath 处理相对路径转绝对路径最简单
只要当前工作目录没被意外改过，Path.GetFullPath 就是首选。它会自动解析 ..、.、重复斜杠、混合斜杠（/ 和 ）等，输出本地风格的绝对路径。
常见错误现象：直接拼字符串或手写正则去“替换 ..”，结果在跨目录层级时算错、忽略驱动器根路径、或在不同系统行为不一致。
-
Path.GetFullPath依赖当前进程的工作目录（Environment.CurrentDirectory），不是编译路径也不是程序集位置 - 如果输入已是绝对路径（如
C:或\servershare），它原样返回，不重新解析网络路径 - 在 .NET Core / .NET 5+ 中支持 Unix 路径（
/home/../tmp→/tmp），但 Windows 上仍默认输出分隔符 - 示例：
Path.GetFullPath("..configpp.json")→"C:\project\config\app.json"（假设当前目录是C:projectsrc）
当工作目录不可靠时，必须显式指定基准路径
Web 应用、服务、单元测试里，Environment.CurrentDirectory 经常不是你想要的起点——比如 IIS 可能设为系统目录，dotnet test 默认在输出目录运行。这时候硬用 Path.GetFullPath 会得到错误结果。
正确做法是先用已知可靠路径（如程序集位置、配置文件路径、IWebHostEnvironment.ContentRootPath）作为基准，再组合：
- 用
Path.Combine(basePath, relativePath)拼接，再传给Path.GetFullPath - 避免直接拼接字符串（如
basePath + "\" + relativePath），容易出双反斜杠或漏分隔符 - 示例：
Path.GetFullPath(Path.Combine(AppContext.BaseDirectory, @"..configsettings.json")) - 注意
AppContext.BaseDirectory是程序集加载根目录，不是.csproj所在目录；调试时可能指向binDebug et6.0
Uri 类不适合路径规范化
有人试过用 new Uri(new Uri(base), relative)，看起来能处理 ..，但这是在做 URI 解析，不是文件路径。结果往往不符合预期。
典型问题：
- 把
C:..c.txt变成file:///C:/a/c.txt（带file://前缀，且斜杠统一为/） - 无法处理 Windows 驱动器号语义（
Uri把C:当作 scheme） - 遇到空格、中文、
#、?会自动编码，生成的路径无法直接用于File.OpenRead - 对 UNC 路径（
\servershare）支持差，容易抛UriFormatException
注意 Path.GetFullPath 的权限与存在性检查
这个函数**不检查路径是否存在，也不校验读写权限**。它只做字符串规范化和逻辑展开。
所以你会遇到这些情况：
-
Path.GetFullPath("nonexistent.. est.txt")依然成功返回"C:\test.txt"（即使nonexistent根本不存在） - 若目标盘符不存在（如
Z:），调用时不会报错，但后续File.Exists或打开操作才会失败 - 在容器或受限环境中，
GetFullPath可能返回合法格式路径，但实际无法访问（如挂载点未映射） - 真正要确认可用性，得在之后加
File.Exists、Directory.Exists或try/catch文件 I/O 异常
C:WindowsSystem32....config.json 这种路径——那说明基准没控住，或者误信了用户输入。 
