路径含空格时 Process.Start
直接失败
Windows 下用
Process.Start启动带空格路径的程序（比如
"C:Program FilesMyApppp.exe"）会报错“系统找不到指定的文件”，不是因为路径不存在，而是 Shell 解析时把空格当成分隔符，只取了
C:Program这一段。
解决方法是显式加双引号包裹整个路径，但注意：不能手动拼接字符串（容易漏转义或引号嵌套出错），应交由系统处理：
用ProcessStartInfo的
FileName只设可执行文件路径（不含参数），
Arguments单独传参 如果必须拼成一条命令，对路径调用
CommandLineToArgvW不现实，更简单的是用
string.Format(@"""{0}""", path) —— 但仅限你完全控制该路径且确认无内部引号
推荐做法：统一用 ProcessStartInfo拆分，例如启动记事本打开带空格的文本文件：
var psi = new ProcessStartInfo("notepad.exe", @"C:My Docseadme.txt");<br>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 中启用：
<configuration><br> <runtime><br> <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false;Switch.System.IO.BlockLongPaths=false" /><br> </runtime><br></configuration>某些第三方库（如旧版
SevenZipSharp）内部仍用 ANSI API，遇到中文路径会静默失败，需查文档或换库
用户输入路径时的空格与截断风险
从
Console.ReadLine()、
TextBox.Text或命令行
args获取路径时，如果用户没加引号（如输入
C:Program Files est.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:"（正确）
Path.Combine("C:\a\", "\b") → ""（第二个参数是绝对路径，前面全部丢弃）
Path.Combine("C:\a", @"bc") → "C:c"（末尾反斜杠会被保留，可能影响后续
Directory.Exists判断） 若拼接结果用于 URL 或跨平台序列化，应再用
path.Replace('\', '/') 标准化，但不要在传给 File.系列方法前这么做
最易被忽略的是：路径末尾的反斜杠在某些 API 中语义不同（比如
Directory.Move对末尾 敏感），拼接后建议用
Path.TrimEndingDirectorySeparator（.NET 5+）或手动
.TrimEnd('\', '/') 清理。 
