Process.Start路径含空格需用ProcessStartInfo拆分FileName和Arguments；File.Exists等支持Unicode但需启用长路径；用户输入路径应避免截断；Path.Combine拼接后建议TrimEndingDirectorySeparator。
路径含空格时 Process.Start 直接失败
Windows 下用 Process.Start 启动带空格路径的程序（比如 "C:\Program Files\MyApp\app.exe"）会报错“系统找不到指定的文件”，不是因为路径不存在，而是 Shell 解析时把空格当成分隔符，只取了 C:\Program 这一段。
解决方法是显式加双引号包裹整个路径，但注意：不能手动拼接字符串（容易漏转义或引号嵌套出错），应交由系统处理：
- 用
ProcessStartInfo的FileName只设可执行文件路径（不含参数），Arguments单独传参 - 如果必须拼成一条命令，对路径调用
CommandLineToArgvW不现实，更简单的是用string.Format(@"""{0}""", path)—— 但仅限你完全控制该路径且确认无内部引号 - 推荐做法：统一用
ProcessStartInfo拆分，例如启动记事本打开带空格的文本文件：var psi = new ProcessStartInfo("notepad.exe", @"C:\My Docs\readme.txt");
Process.Start(psi);
File.Exists 和 Directory.GetDirectories 对 Unicode 路径的支持
C# 的 File.Exists、Directory.GetFiles 等 API 默认支持 Unicode 路径（如含中文、emoji、全角空格），但前提是你的程序没有禁用长路径支持，且 Windows 版本 ≥10 1607。
常见陷阱：
- Windows 旧版本默认限制 260 字符路径（
MAX_PATH），超长路径会返回false或抛PathTooLongException，即使路径真实存在 - .NET Core 3.0+ 和 .NET 5+ 默认启用长路径，但 .NET Framework 需在 app.config 中启用：
- 某些第三方库（如旧版
SevenZipSharp）内部仍用 ANSI API，遇到中文路径会静默失败，需查文档或换库
用户输入路径时的空格与截断风险
从 Console.ReadLine()、TextBox.Text 或命令行 args 获取路径时，如果用户没加引号（如输入 C:\Program Files\test.txt），args[0] 实际只拿到 C:\Program。
应对策略：
- 命令行场景：用
Environment.GetCommandLineArgs()替代args，它会按系统规则解析引号，保留完整路径 - GUI 场景：用
OpenFileDialog或FolderBrowserDialog，它们返回的路径已规范化且带引号保护，无需额外处理 - 必须手输路径时：先用
Path.GetFullPath(input)尝试标准化，再检查是否以:开头或含\，避免把纯文件名误判为路径
反斜杠、正斜杠与 Path.Combine 的实际行为
Windows 路径中混用 / 和 \ 通常能被 API 自动兼容（如 File.ReadAllText("C:/Temp/file.txt") 可正常工作），但依赖此行为不安全。真正可靠的做法是统一用 Path.Combine 拼接，它会自动选用当前系统的目录分隔符。
注意几个边界情况：
-
Path.Combine("C:\\", "a", "b")→"C:\a\b"（正确） -
Path.Combine("C:\\a\\", "\\b")→"\b"（第二个参数是绝对路径，前面全部丢弃） -
Path.Combine("C:\\a", @"b\c\")→"C:\a\b\c\"（末尾反斜杠会被保留，可能影响后续Directory.Exists判断） - 若拼接结果用于 URL 或跨平台序列化，应再用
path.Replace('\\', '/')标准化，但不要在传给File.系列方法前这么做
最易被忽略的是：路径末尾的反斜杠在某些 API 中语义不同（比如 Directory.Move 对末尾 \ 敏感），拼接后建议用 Path.TrimEndingDirectorySeparator（.NET 5+）或手动 .TrimEnd('\\', '/') 清理。
