Path类是路径操作唯一安全入口，必须用Path.Combine替代字符串拼接，因后者跨平台失效、易出转义错误；GetFullPath需指定基准目录；GetFileName等对末尾分隔符敏感；临时文件需手动清理。
Path 类不是“辅助工具”，它是路径操作的唯一安全入口——手动拼接字符串（比如 "C:\config\" + fileName）在 .NET 5+ 中等同于埋雷。
Path.Combine 为什么必须用，而不是字符串拼接
Windows 用反斜杠 ，Linux/macOS 用正斜杠 /，而 Path.Combine 自动适配当前运行平台的 Path.DirectorySeparatorChar。手动拼接不仅跨平台失效，还会因多一个或少一个分隔符导致路径错位（比如 "logs\" + "app.log" 可能变成 "logs\app.log"，但在某些场景下又可能被解释为转义序列）。
常见错误现象：File.Exists("C:logspp.log") 编译失败（l、 被识别为转义字符）；或运行时返回 false，因为实际路径是 C:logsapp.log。
- 永远用
Path.Combine("C:", "logs", "app.log")，而不是"C:" + "\" + "logs" + "\" + "app.log" - 传入空字符串或
null会抛ArgumentNullException，需提前校验 - 多个参数中任意一个含完整路径（如
"C:\temp\file.txt"），前面所有参数会被丢弃——这是设计行为，不是 bug
GetFullPath 处理相对路径时的基准目录陷阱
Path.GetFullPath 不读取文件系统，只做字符串解析：它以「当前工作目录」（Environment.CurrentDirectory）为基准展开相对路径。这个目录和程序集位置（AppContext.BaseDirectory）经常不一致，尤其在调试、服务部署、ClickOnce 或 dotnet run 场景下。
典型问题：Path.GetFullPath("config.json") 在 Visual Studio 调试时指向项目根目录，但发布后可能指向 C:WindowsSystem32（如果服务未显式设置工作目录）。
- .NET 5+ 推荐显式指定基准：
Path.GetFullPath("config.json", AppContext.BaseDirectory) - 旧版本兼容写法：
Path.GetFullPath(Path.Combine(AppContext.BaseDirectory, "config.json")) - 必须捕获
ArgumentException（含非法字符如< > | ? *）和IOException（路径长度超 260 字符），生产环境不 catch 就是放任崩溃
GetFileName 和 GetExtension 对末尾分隔符的敏感行为
Path.GetFileName 和 Path.GetExtension 的逻辑基于「最后一个分隔符位置」。如果路径以 或 / 结尾，它们会认为这是目录路径而非文件路径，于是返回空字符串。
错误示例：Path.GetFileName(@"C:data
eport") → ""（不是 "report"）；Path.GetExtension(@"C:data
eport.") → "."（注意这个点是合法扩展名）。
- 判断是否为文件路径，优先用
Path.HasExtension(path) && !path.EndsWith(Path.DirectorySeparatorChar.ToString()) - 提取文件名前先用
Path.GetFileNameWithoutExtension+Path.GetExtension组合，比直接切字符串更可靠 -
Path.GetInvalidFileNameChars()返回的非法字符数组，可用于预清洗用户输入的文件名
临时路径和随机文件名的正确打开方式
Path.GetTempPath() 返回的是系统级临时目录（如 C:UsersXXXAppDataLocalTemp），但它不保证可写——尤其在受限账户、容器或 CI 环境中。而 Path.GetRandomFileName() 生成的是 11 字符小写+数字组合（如 "4v2x9m1a.tmp"），不含路径，也不创建文件。
- 不要直接拼接：
Path.Combine(Path.GetTempPath(), Path.GetRandomFileName())是安全的起点，但记得用File.Create或Path.GetTempFileName()（后者会立即创建并返回唯一路径） -
Path.GetTempFileName()有上限（约 65535 个未清理文件后抛IOException），高并发场景应改用Path.GetRandomFileName()+ 显式FileStream创建 - 临时文件用完务必
File.Delete，否则可能占满磁盘——.NET 不自动清理
Path 类所有方法都假设输入是合法路径字符串。它不做 I/O，也不验证目标是否存在；真正的风险藏在「你以为它存在」和「它其实根本拼错了」之间。最常被忽略的一点：没有哪个方法能替代 File.Exists 或 Directory.Exists 的最终校验。
