path.combine能跨平台是因为它自动适配运行时分隔符并规范化路径，而硬编码"a/b/c.txt"依赖字符串字面量，在linux可能非法、windows仅靠兼容性侥幸成功；它不校验非法字符但避免分隔符错位，且不处理语义归一化，需配合getfullpath等使用。
直接用 Path.Combine 就行，但必须全程不用手动拼接、不硬编码分隔符、不依赖字符串替换 —— 否则看似能跑，上线就崩。
为什么 Path.Combine 能跨平台，而 "a/b/c.txt" 不能保证安全
Windows 文件系统层确实接受正斜杠 / 作为替代分隔符，所以 "x86/ShaferFilechck.dll" 在 Windows 上常能“侥幸”加载成功。但这只是兼容性红利，不是设计保障：
-
Path.Combine("x86", "ShaferFilechck.dll")在 Windows 返回"x86ShaferFilechck.dll"，在 Linux 返回"x86/ShaferFilechck.dll"，结果由运行时环境决定，不依赖字符串字面量 - 如果路径片段本身含非法字符（如
":"或"*"），Path.Combine不会校验，但至少不会因分隔符错位导致解析失败 - 混合写法如
"data\subdir/file.txt"在某些 .NET 版本或容器环境中会被File.Exists误判为无效路径（尤其涉及 UNC 或长路径时）
Path.Combine 的典型误用场景和修复方式
常见错误不是函数不会用，而是把它当成“字符串拼接加强版”，仍混入手写分隔符：
- ❌ 错误：
Path.Combine("C:\data", "config.json")—— 硬编码C:根路径，Linux 上直接抛ArgumentException - ❌ 错误：
Path.Combine(baseDir + "/", filename)—— 先字符串拼接再传入，baseDir若已带尾部，结果变成"C:data/config.json"，部分 API（如AssemblyLoadContext.LoadFromAssemblyPath）会拒绝 - ✅ 正确：用
Path.GetFullPath+Path.Combine组合处理相对路径：Path.GetFullPath(Path.Combine(AppContext.BaseDirectory, "plugins", "loader.dll")) - ✅ 正确：对用户输入路径先用
Path.GetInvalidPathChars()过滤，再进Combine，避免注入式路径遍历
遇到 UNC 路径、驱动器号、相对路径时怎么选方法
Path.Combine 只负责拼接，不负责语义归一化。复杂路径需搭配其他 Path 方法：
- UNC 路径（
\servershare ile.txt）：直接传入Path.Combine没问题，但若要确保格式统一，可用Path.GetFullPath触发规范化（注意：它在 Linux 上对 UNC 会抛异常，需提前判断Path.IsPathRooted） - 含驱动器号的绝对路径（
C: emp）：Path.Combine("C:\temp", "log.txt")结果仍是C: emplog.txt；但Path.Combine("C:\temp", "D:\backup ile.txt")会丢弃前面的C: emp，只返回D:ackup ile.txt—— 这是设计行为，不是 bug - 相对路径（
"../config/app.json"）：Path.Combine不会自动解析..，要用Path.GetFullPath或Path.GetRelativePath（.NET 5+）进一步处理
真正容易被忽略的是：路径是否“可执行”不只看分隔符，还取决于当前进程工作目录、权限、文件系统大小写策略（Linux/macOS 区分大小写，Windows 默认不区分）。Path.Combine 解决的是“怎么写才不会语法出错”，而不是“写了就一定能打开”。
