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:pp"; string file = Path.Combine(basePath, "settings", "user.json"); // ✅ 得到 C:ppsettingsuser.json string bad = Path.Combine(basePath, @"D:overrideconf.txt"); // ❌ 得到 D:overrideconf.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: emp")); // 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解析用户输入路径，可能成为瓶颈（尤其含大量
..时） 若传入含非法字符（如
<code>、<code>|、
*）的字符串，
GetFullPath仍会返回结果，但后续
File.Open才真正失败 在 .NET 5+ 中，
GetFullPath对 UNC 路径（
\servershare）支持更好；旧版可能意外截断
string input = @"....config..datasettings.json"; string resolved = Path.GetFullPath(input); // 假设当前目录是 C:ppsrc，结果是 C:ppdatasettings.json // 即使 C:ppdata 不存在，这里也完全不会报错路径规范化这件事，表面只是字符串处理，实际牵扯到权限判断、配置加载、日志归档、甚至反路径遍历攻击防御。别只盯着
Combine和
GetExtension，
IsPathRooted和
GetFullPath的返回值含义，才是线上环境出问题时最常被忽略的环节。
