Path.Combine 应替代 + 拼接以适配系统分隔符并处理空段和根路径覆盖；Path.GetExtension 仅取最后一段扩展名，不支持复合扩展；Path.IsPathRooted 仅判断是否以根开头，不验证存在性；Path.GetFullPath 仅规范化路径，不校验文件是否存在。

Path.Combine 为什么拼接路径时不能直接用 + 号

因为不同操作系统路径分隔符不同（Windows 是 \，Linux/macOS 是 /），硬拼字符串容易出错。比如 "C:\\data" + "/" + "config.txt" 在 Windows 上会变成 C:\data/config.txt，虽然多数 .NET API 能容忍，但可读性差

、跨平台不可靠。Path.Combine 自动适配当前系统分隔符，并处理冗余分隔符和空段。

实操建议：

• 始终用 Path.Combine 拼接路径，哪怕只有两段
• 传入的任意参数为 null 或空字符串时，Path.Combine 会跳过它，不会报错
• 如果某段以根目录开头（如 "D:\\logs" 或 "/tmp"），后续段会被忽略——这是常见误用点

string basePath = @"C:\app";
string file = Path.Combine(basePath, "settings", "user.json"); // ✅ 得到 C:\app\settings\user.json
string bad = Path.Combine(basePath, @"D:\override\conf.txt"); // ❌ 得到 D:\override\conf.txt（basePath 被丢弃）

Path.GetExtension 和 Path.GetFileNameWithoutExtension 的边界行为

这两个方法看似简单，但对带多个点、无扩展名、隐藏文件等场景有明确规则。比如 Path.GetExtension("archive.tar.gz") 返回 ".gz"（只取最后一个点之后），而 Path.GetFileNameWithoutExtension("readme.") 返回 "readme."（末尾点不视为扩展名分隔符）。

常见错误现象：

• 误以为 Path.GetExtension 能识别复合扩展名（如 .tar.gz），实际不支持
• 对 "file"（无点）、"file."（末尾点）、".gitignore"（隐藏文件）返回结果不符合直觉
• 在判断是否为图片时写成 Path.GetExtension(path) == ".jpg"，没转小写，导致 .JPG 不匹配

Console.WriteLine(Path.GetExtension("a.b.c"));        // ".c"
Console.WriteLine(Path.GetExtension(".bashrc"));      // ""
Console.WriteLine(Path.GetExtension("archive."));     // "."
Console.WriteLine(Path.GetFileNameWithoutExtension(".gitignore")); // ".gitignore"

Path.IsPathRooted 判断失败的典型原因

Path.IsPathRooted 返回 false 并不一定代表路径是相对的——它只检查是否“以根开头”，比如 "C:\temp" 是根路径，但 "C:temp"（缺 \）不是，"/home/user" 是，但 "home/user" 不是。很多配置读取或日志模块依赖这个判断做路径补全，结果悄悄出错。

使用场景与注意点：

• Web 应用中从配置读取日志路径，若写成 "logs/app.log"，IsPathRooted 返回 false，程序可能自动拼上 AppDomain.CurrentDomain.BaseDirectory，但你本意是想用绝对路径
• Path.IsPathRooted 不验证路径是否存在，也不检查盘符是否真实（"Z:\\test" 也会返回 true）
• 在容器或跨平台部署时，Linux 下 "~/data" 不是根路径（~ 是 shell 层展开的，.NET 不处理）

Console.WriteLine(Path.IsPathRooted(@"C:\temp"));   // True
Console.WriteLine(Path.IsPathRooted("C:temp"));     // False（缺少反斜杠）
Console.WriteLine(Path.IsPathRooted("/etc/hosts")); // True（Unix 根）
Console.WriteLine(Path.IsPathRooted("~/config"));   // False（~ 不被识别）

Path.GetFullPath 的陷阱：它不校验文件是否存在，但会解析 .. 和 .

Path.GetFullPath 主要作用是规范化路径（消除 ..、.、重复分隔符），并补全为绝对路径。但它**完全不访问磁盘**，所以即使路径指向一个根本不存在的目录，也不会报错。这导致很多开发者误以为调用它就等于“路径安全”了。

性能与兼容性影响：

• 在高并发日志写入场景中，频繁调用 GetFullPath 解析用户输入路径，可能成为瓶颈（尤其含大量 .. 时）
• 若传入含非法字符（如 、|、*）的字符串，GetFullPath 仍会返回结果，但后续 File.Open 才真正失败
• 在 .NET 5+ 中，GetFullPath 对 UNC 路径（\\server\share）支持更好；旧版可能意外截断

string input = @"..\..\config\..\data\settings.json";
string resolved = Path.GetFullPath(input); 
// 假设当前目录是 C:\app\src，结果是 C:\app\data\settings.json
// 即使 C:\app\data 不存在，这里也完全不会报错

路径规范化这件事，表面只是字符串处理，实际牵扯到权限判断、配置加载、日志归档、甚至反路径遍历攻击防御。别只盯着 Combine 和 GetExtension，IsPathRooted 和 GetFullPath 的返回值含义，才是线上环境出问题时最常被忽略的环节。